On Fri, Apr 8, 2016 at 10:26 PM, Tanja Lange <[email protected]> wrote:
> Looks like this didn't make it out to the list. Forwarding > from my email address a message by Jon Solworth. > > ----- Forwarded message from "Jon A. Solworth" <[email protected]> > ----- > > Date: Fri, 8 Apr 2016 17:33:57 -0500 > From: "Jon A. Solworth" <[email protected]> > To: [email protected], Tanja Lange <[email protected]>, "D. J. Bernstein" > <[email protected]>, "W. Michael Petullo" <[email protected]> > Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto > > It is not necessary to choose between either forward secrecy > or low latency. It is possible to achieve both (and many other > properties) as does MinimaLT. > > In MinimaLT, the current ephemeral key for the server > is added to the DNS record fetched during the DNS lookup. These entries > expire fairly quickly, ensuring that old keys are never > used. > > The DNS lookup is necessary for other reasons, so there > is no additional latency. > DNS-based priming is a seemingly attractive concept but unfortunately isn't really workable here, for several reasons: 1. It requires DNS security, which has relatively minimal deployment. We want 0-RTT to be available in TLS 1.3 even in environments without DNS security. 2. Measurements indicate that penetration rates for DNS records other than the basic ones that are necessary for nearly all operation (A, CNAME, etc.) are fairly poor, so this adds a number of operational problems. If you want to use short-lived ephemerals that are frequently refreshed in the DNS, thus providing forward secrecy you have the additional problem that most Web servers are not well integrated into the DNS server (one reason why Let's Encrypt initially launched with HTTP-based validation). With that said, if the deployment situation changes, it wouldn't be that hard to add a feature like this to TLS 1.3 in the future. Best, -Ekr > This design avoids weak mechanisms and added complexity, > two issues that cause enormous problems in security software. > > Jon Solworth > > ----- End forwarded message ----- > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
