On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote: > * 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.)
This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
client deliberately fail a connection when the problem might be a flaw
with an unrelated network service or a client-specific routing failure?
I think we can definitely explicitly recommend:
A) clients MUST require valid stapled OCSP response when encountering a
certificate with "must staple" extension. (this is just following
the specs, but i don't think it's as widely supported as it should
be; maybe we need some public naming/shaming?)
I'm less sure about, but could be convinced of:
B) server operators SHOULD use certificates with "must staple"
extension.
Figuring out how to properly incentivize (B) is the hard part.
It looks a lot like the "you should adopt DNSSEC" argument. Most
sysadmins find that unconvincing, because they hear it as "your network
services need this additional point of failure".
Plus, adopting this for your own certificates only helps in the event of
secret key theft that the legit admin notices -- she can then respond by
revoking the key and trusting the OCSP responder to not issue valid OCSP
responses.
As Victor rightly points out, a more likely threat model today is that
the adversary spoofs your DNS or your routing, and uses that spoofing to
get one of the ACME providers (e.g., let's encrypt) to issue new
certificates entirely.
So the right set of fixes to defend against all these kinds of attacks
are:
- enable DNSSEC for your zone
- signal in your DNS (e.g. via CAA, RFC 8659) that you only want a
specific set of CAs to issue certificates in your zone (CAA doesn't
explicitly describe an option to require that the CA use must-staple,
but it looks like any CA could declare a CAA parameter that would
offer that guidance. for example:
https://github.com/letsencrypt/boulder/issues/5903)
- ensure that your account with those CAs requires must-staple (either
with your CA's preferred CAA parameter, or some other way)
- monitor CT logs for certificates that violate your CAA policy
This should close all the gaps that i can see, making the whole chain as
strong as your control over what gets signed by your zone's DNSSEC
signing key (and your CA's adherence to CAA policy, of course).
--dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
