Subject: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 08:08:20 +0000

Hi Mohit,

  *   I think it is a reasonable compromise for servers to implement OCSP stapling. Clients can implement and use it, but they would be compliant even if they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use Certificate Status Requests for the server's certificate chain and it MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am looking forward to see OCSP supported added to EDHOC by John.

From: Emu <[email-masked]> On Behalf Of Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: [email-masked]
Subject: [Emu] Moving towards less security in 2020 - OCSP

Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect whatever the working group wants. The authors and contributors are at the service of the working group. Obviously it is easy for us to simply change all MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I am saddened by the discussion thus far. To begin with, I assume that everyone knows the difference between OCSP and OCSP stapling. I also hope that everyone has read RFC 5216 (the previous EAP-TLS specification). In particular I hope that the working group has actually read section 5.4 on "Certificate Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 of<https://tools.ietf.org/html/rfc3280#section-3.3>

   [RFC3280]<https://tools.ietf.org/html/rfc3280#section-3.3>.  EAP-TLS peer and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560<https://tools.ietf.org/html/rfc2560>].  OCSP messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of [RFC4366]<https://tools.ietf.org/html/rfc4366#section-3.6>.  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was published. And now 12/13 years later, some people in the working group are suggesting to make the security stance weaker. For what? Some speculative insecure future deployments? Please note that EAP-TLS is currently implemented in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid of the text on OCSP. He wrote "I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you see, RFC 5216 has quite detailed guidelines on certificate revocation checking with CRLs and OCSP so I don't see any sensible reason on why an update to it should not contain relevant text. Michael wrote " we are under no additional compulsion to support revocation than we were before." Do you see the problem here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their views, we also saw feedback from Janfred explaining the situation without OCSP in a live network like eduroam: https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends his email with

All in all, I definitely think that making OCSP Stapling optional will

have a benefit on small devices, but especially for the diverse

environment of eduroam, making OCSP Stapling mandatory will increase the

overall security of this federation.

Maybe it might be a good idea to make OCSP Stapling mandatory for

EAP-TLS Servers?

So where we are with the current draft. The current draft (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4) says, "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation status of the certificates in the client's certificate chain.". It doesn't mandate any specific technique. You are free to use whatever propriety (potentially insecure) method you want. The revocation checking could use the following pseudocode for checking the revocation status of client certificates:

fun check_revocation {
return success;
}

and you would comply with specification. Naturally, using CRLs or locally-configured OCSP responder on the server (for revocation checking of client certificates) will get you better security. The current text in the draft does mandate OCSP stapling for clients to verify the revocation status of server certificates. Given the resistance in the working group, I think it is a reasonable compromise for servers to implement OCSP stapling. Clients can implement and use it, but they would be compliant even if they don't. So the updated text would be (as Joe wrote in his email):
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for verifying the status of server certificates as specified in Section 4.4.2.1 of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate status of the EAP-TLS server, it MUST use Certificate Status Requests for the server's certificate chain and it MUST treat a CertificateEntry (except the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert.

Note that this is also compliant with the NIST SP 800-52 Rev. 2.

--Mohit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 2 Nov 2020 08:57:29 +0000

Et voilà, we seem to be moving towards a consensus!

--Mohit

PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its high time. There have been several requests for this already for a few years: https://github.com/ARMmbed/mbedtls/issues/880

On 11/2/20 10:08 AM, Hannes Tschofenig wrote:
Hi Mohit,

Ciao
Hannes

From: Emu <[email-masked]><mailto:[email-masked]> On Behalf Of Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Emu] Moving towards less security in 2020 - OCSP

Dear all,

EAP-TLS Servers?

fun check_revocation {
return success;
}

--Mohit

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 09:42:27 +0000

Hi Mohit,

> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.

> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it complete.

>  There have been several requests for this already for a few years: https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed TLS this is close to “zero interest”.

Ciao

Hannes

---

From: Eliot Lear <[email-masked]>
Date: Mon, 2 Nov 2020 12:26:53 +0100

Hi Hannes,

My concern is not about implementation.  At least for the sake of discussion, let us assume that we can get the code to where it needs to be.  The question is more about what happens when an OCSP server is unavailable, either to the client or to the server (stapled or otherwise).  What is expected of server behavior in such a case, and what is expected of client behavior?

Consider the scenario when you have the CA sitting off somewhere in the distance, and a power failure or other service interruption has occurred.  Should the client refuse to come up because stapling didn’t happen?  Should old stapling information be retained, and what does that mean in the context of the nonce extension?  I had thought we said that this risk is mitigated by the choice of the deployment to include the OCSP extension information in the cert- or not.  At that point the deployment can make the decision.

Are we now saying otherwise?

Eliot

> On 2 Nov 2020, at 09:08, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Mohit, 
>  
> I think it is a reasonable compromise for servers to implement OCSP stapling. Clients can implement and use it, but they would be compliant even if they don't. So the updated text would be (as Joe wrote in his email):
> “ 
> From: Emu <[email-masked] <mailto:[email-masked]>> On Behalf Of Mohit Sethi M
> To: [email-masked] <mailto:[email-masked]>
> Yet, I think as a conscientious security person and individual contributor, I am saddened by the discussion thus far. To begin with, I assume that everyone knows the difference between OCSP and OCSP stapling. I also hope that everyone has read RFC 5216 (the previous EAP-TLS specification). In particular I hope that the working group has actually read section 5.4 on "Certificate Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4 <https://tools.ietf.org/html/rfc5216#section-5.4>). I copy the relevant text here for your convenience:
> 
>    Certificate Revocation Lists (CRLs); for details, see Section 3.3 of <https://tools.ietf.org/html/rfc3280#section-3.3>
>    [RFC3280] <https://tools.ietf.org/html/rfc3280#section-3.3>.  EAP-TLS peer and server implementations SHOULD also
>    Protocol - OCSP" [RFC2560 <https://tools.ietf.org/html/rfc2560>].  OCSP messages are typically much smaller
>    Security (TLS) Extensions", Section 3.6 of [RFC4366] <https://tools.ietf.org/html/rfc4366#section-3.6>.  To enable
> While Elliot and Hannes have been vocal about their views, we also saw feedback from Janfred explaining the situation without OCSP in a live network like eduroam:https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/ <https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/>. He ends his email with
> 
> So where we are with the current draft. The current draft (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4 <https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4>) says, "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation status of the certificates in the client's certificate chain.". It doesn't mandate any specific technique. You are free to use whatever propriety (potentially insecure) method you want. The revocation checking could use the following pseudocode for checking the revocation status of client certificates:
> 
> fun check_revocation {
> return success;
> }
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
> Emu mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/emu <https://www.ietf.org/mailman/listinfo/emu>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 11:33:32 +0000

I agree with you, Eliot.

I don’t understand for what certificates we would be using OCSP in the EAP-TLS context, and what would happen if OCSP checks fail.

Ciao
Hannes

From: Eliot Lear <[email-masked]>
Sent: Monday, November 2, 2020 12:27 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Mohit Sethi M <mohit.m.sethi=[email-masked]>; [email-masked]
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

Hi Hannes,

Eliot

On 2 Nov 2020, at 09:08, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mohit,

Ciao
Hannes

From: Emu <[email-masked]<mailto:[email-masked]>> On Behalf Of Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Emu] Moving towards less security in 2020 - OCSP

Dear all,

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was published. And now 12/13 years later, some people in the working group are suggesting to make the security stance weaker. For what? Some speculative insecure future deployments? Please note that EAP-TLS is currently implemented in billions of devices and used in many high security deployments.
It is very surprising to see Hannes wanting to water down security and get rid of the text on OCSP. He wrote "I do not understand certificate revocation checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you see, RFC 5216 has quite detailed guidelines on certificate revocation checking with CRLs and OCSP so I don't see any sensible reason on why an update to it should not contain relevant text. Michael wrote " we are under no additional compulsion to support revocation than we were before." Do you see the problem here given the text in RFC 5216 shown above?
While Elliot and Hannes have been vocal about their views, we also saw feedback from Janfred explaining the situation without OCSP in a live network like eduroam:https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends his email with

EAP-TLS Servers?

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 2 Nov 2020 11:35:54 +0000

Hi Hannes,

On 11/2/20 11:42 AM, Hannes Tschofenig wrote:
Hi Mohit,

That’s indeed exciting.

You are probably right here. This is the unfortunate reality for many open source projects. While writing some code with openssl, I (and others) had requested a feature to export x25519 public keys: https://github.com/openssl/openssl/pull/5520#issuecomment-391088904. Not sure how far that has come along.

--Mohit

Ciao

Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 2 Nov 2020 11:41:53 +0000

FWIW there is a public Mbed TLS virtual workshop tomorrow (see https://www.trustedfirmware.org/meetings/mbed-tls-workshop/).
Those who care about any of these security features could join, and ask for the support of x, y and z.

Ciao
Hannes

From: Mohit Sethi M <[email-masked]>
Sent: Monday, November 2, 2020 12:36 PM
To: Hannes Tschofenig <[email-masked]>; Mohit Sethi M <[email-masked]>; Mohit Sethi M <mohit.m.sethi=[email-masked]>; [email-masked]
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

Hi Hannes,

That’s indeed exciting.

--Mohit

Ciao

Hannes

Emu mailing list

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2020 10:40:27 -0500

Eliot Lear <lear=[email-masked]> wrote:
    > Consider the scenario when you have the CA sitting off somewhere in the
    > distance, and a power failure or other service interruption has
    > occurred.  Should the client refuse to come up because stapling didn’t
    > happen?  Should old stapling information be retained, and what does
    > that mean in the context of the nonce extension?  I had thought we said
    > that this risk is mitigated by the choice of the deployment to include
    > the OCSP extension information in the cert- or not.  At that point the
    > deployment can make the decision.

Eliot,

1) it seems that if the CA hasn't put stapling information in, then it won't be needed.

2) if you still want stapling, then it seems to me that there are lifetimes in the
   staple which can be adjusted to deal with anticipated service
   interruptions in connectivity to the CA.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide