Subject: Re: [Emu] Moving towards less security in 2020 - OCSP

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Nov 2020 11:48:10 -0500

Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
    > 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.

I don't think that people were saying it should be weaker than SHOULD.
I also think that there is a distinction between MTI and mandatory to use
which has gotten lost.

And I think that there is also a significant distinction between a server
supporting answering OCSP staples, vs a client being forced to ask for it.

If the CA doesn't put any OCSP data into a certificate, then it can't be
used. That's a local decision.

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

---

From: Mohit Sethi M <[email-masked]>
Date: Sun, 1 Nov 2020 17:18:50 +0000

Hi Michael,

Absolutely, the text which Joe sent (with subject Consensus Call on OCSP usage), and which I re-iterated in my email is only saying that OCSP stapling is mandatory to implement on the server. Clients SHOULD implement and use it but of course they are free not do so.

However, you suggested a modification:

I suggest:

“EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
recovation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446].

I think this is mangled and incorrect. This text doesn't clearly say that OCSP stapling is mandatory-to-implement on the server. This text also says "EAP-TLS servers ..... MUST implement Certificate Status Requests using OCSP stapling as specified in....." whereas the request is sent by the peer.

But thankfully we are in agreement on what the draft should say. I am sure we can reach an agreement on the exact wording. How would you want us to update the text:

EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446]. EAP-TLS peers and servers SHOULD 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.

--Mohit

On 11/1/20 6:48 PM, Michael Richardson wrote:

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

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