> On 19 Jan 2022, at 9:57 am, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
>
> 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:
> • 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.)
IMHO unrealistic and self-defeating.
> • Remove the whole discussion of OCSP, saying that in its current form
> it’s not adding value.
Largely this.
> • Maintain the status quo, where many people implement OCSP on the
> server side, but clients rarely benefit.
Or this.
> 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.
For example "Let's Encrypt" supports issuing certificates with "must staple",
but this an opt-in feature. So as an attacker who can impersonate the subject,
I won't ask for "must staple", and so this is just security theatre.
In Postfix, I have elected to not waste time supporting either CRLs or OCSP.
If one wants TLS-authenticated SMTP one can use DANE, where there's no need
for "revocation", just publish a fresh TLSA RRset that does not match any
compromised keys or unauthorised certificates.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
