On Mar 30, 2016 9:03 AM, "Daniel Kahn Gillmor" <[email protected]> wrote: > > On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote: > > This got a lot of discussion early in the design process and the consensus > > was that the risk of having the default mode (with existing certs) allow the > > creation of a long-term delegation was too high. See, for instance, the > > relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and > > QUIC. > > > > With that said, I think this would be a good feature to look at in future > > and the right way to do it is to: > > > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > > PKIX. > > this would need to be a critical extension, since the goal is to have it > be unusable by existing endpoints, right? do we have tests about how > well existing endpoints will fail closed in the face of unknown critical > extensions?
This won't work to protect against a server misconfigured to use the RSA EE certificate for Bleichenbacher vulnerable handshakes. We would need to limit to ECDSA certs and ensure that the subcert cannot be gamed into being something else that might get signed by a TLS server. > > > 2. Add a subcert extension to TLS 1.3. > > This would be necessary for clients to signal that it's ok to use such a > delegated cert or subcert. we need to think clearly about how to limit > the scope of such a delegation to make it safe. > > --dkg > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
