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
