Hi Yaron,
That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS)
and also in IoT environments where it just don’t make a lot of sense to me.
Hence, I would like to understand the motivation behind it and the use cases.
Ciao
Hannes
From: Yaron Sheffer <yaronf.i...@gmail.com>
Sent: Thursday, January 20, 2022 3:18 PM
To: Hannes Tschofenig <hannes.tschofe...@arm.com>; u...@ietf.org; tls@ietf.org
Subject: Re: OCSP in RFC7525bis
Hi Hannes,
This is not about my personal beliefs. RFC 7525 looks at certificate revocation
in the context of TLS (and not only TLS for Web use but the broader ecosystem)
and recommends OCSP and OCSP Stapling as the best available techniques to
enable effective certificate revocation, but with caveats. It’s been more than
6 years since the RFC was published, and we are reviewing our recommendations,
which may or may not still be valid.
Thanks,
Yaron
From: Hannes Tschofenig
<hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>>
Date: Thursday, January 20, 2022 at 12:00
To: Yaron Sheffer <yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>>,
u...@ietf.org<mailto:u...@ietf.org> <u...@ietf.org<mailto:u...@ietf.org>>,
tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>
Subject: RE: OCSP in RFC7525bis
Hi Yaron,
Where do you believe OCSP will be a good fit and why?
Ciao
Hannes
From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> On Behalf Of
Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org<mailto:u...@ietf.org>; tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] OCSP in RFC7525bis
Hi,
RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use
OCSP and OCSP stapling. We are changing these recommendations [2] in view of
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.
But this raises a larger question: many client-side implementations soft-fail
if they don’t get an OCSP response within the handshake, i.e. they just ignore
the problem. As far as we understand, this makes OCSP stapling completely
ineffective for what it’s trying to solve.
So for the new BCP, we have three options:
1. Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly
also TLS 1.2 implementations) to fail the handshake if the OCSP response is
missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
2. Remove the whole discussion of OCSP, saying that in its current form
it’s not adding value.
3. Maintain the status quo, where many people implement OCSP on the server
side, but clients rarely benefit.
We would be grateful for feedback based on implementation experience. In
particular if you have quantitative data on the use or quality of OCSP that’s
more recent than Chung18 [3], that would be very useful.
Thanks,
Peter, Thomas and Yaron
PS: apologies for cross-posting.
[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files
[3] https://cbw.sh/static/pdf/chung-imc18.pdf
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.
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
