To add one more point here: the WG was very uncomfortable with having any kind of long-term delegation mechanism, which a static signature of this type would be (though perhaps it would be a weaker form of attack if you required an online signature as part of the handshake, as draft-12 does, in which case the attack would be limited to the 0-RTT data).
-Ekr On Mon, Apr 11, 2016 at 10:10 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein <d...@cr.yp.to> wrote: > >> Eric Rescorla writes: >> > DNS-based priming is a seemingly attractive concept but unfortunately >> isn't >> > really workable here, for several reasons: >> > 1. It requires DNS security >> >> No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy >> deployability. The same server key that you're using for HTTPS, the key >> where you've obtained a certificate from (say) Let's Encrypt, is also >> signing your MinimaLT ephemeral keys. (Improvements in DNS security can >> give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas >> TLS doesn't have this feature, but this is not the main point.) >> > > Yes, this is a fair point. > > > You _do_ need to be able to automatically sign new ephemeral keys and >> drop the signed data into your DNS database. If you're not used to this >> level of automation---for example, if you've outsourced your DNS data to >> a company that provides only manual web-based DNS editing---then you >> might see this as a showstopper. But there are many other sites where >> this is a trivial level of scripting. The resulting latency improvement >> is huge---_always_ getting what 0RTT _sometimes_ gets. > > > Perhaps: Google's measurements indicate a very high rate of 0-RTT with > QUIC (75%) without DNS-based priming. > > > >> > 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. >> >> I agree that the original goal of extensible "query types" in DNS (see >> RFC 1034, third paragraph) was ruined by poor implementation work (which >> was in turn encouraged by other aspects of the DNS protocol design, but >> let me not get sidetracked here), so trying to deploy new DNS "query >> types" creates operational problems. >> >> This does _not_ mean, however, that putting new applications into DNS >> creates operational problems. It simply means that one has to avoid the >> trap of thinking that new applications should encode their data as new >> DNS "query types". Sticking to the limited set of well-supported DNS >> "query types" is reasonably straightforward and eliminates all of the >> operational problems. > > > I'm not sure which query type you're assuming: the measurements I am > referring to were taken with TXT records. > > To be clear: I wish this weren't true. Expecting to have some kind of > out-out-band > priming was one of the main reasons for having a DH-based 0-RTT mode in > draft-12, but increasingly it just started to look like that wasn't viable. > > -Ekr >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
