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 <hannes.tschofe...@arm.com > <mailto:hannes.tschofe...@arm.com>> 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): > “ > 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 <emu-boun...@ietf.org <mailto:emu-boun...@ietf.org>> On Behalf Of > Mohit Sethi M > Sent: Saturday, October 31, 2020 2:15 PM > To: emu@ietf.org <mailto:emu@ietf.org> > 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 > <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/ > <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 > <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. > _______________________________________________ > Emu mailing list > Emu@ietf.org <mailto:Emu@ietf.org> > https://www.ietf.org/mailman/listinfo/emu > <https://www.ietf.org/mailman/listinfo/emu>
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
