Hiya, On 03/07/18 00:39, Eric Rescorla wrote: > Hi folks, > > I just submitted: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00
Thanks for writing that up. I think it's an interesting addition to the set of potential solutions. > > This draft describes a DNS-based approach to doing encrypted SNI. > > Previously, we had thought this wouldn't work because only sites that > were particularly vulnerable would do it, and so the use of ESNI marks > you out. The idea behind this draft is that there are a lot of sites > which are hosted by -- and whose DNS is run by -- a large provider, > and that provider can shift many if not all of its sites to ESNI at > once, thus removing the "standing out" issue and making a DNS-based > approach practical. I'm not sure I fully understand how this approach would fit with others, nor to what extent it depends on the DNS and CDN providers co-operating, but it definitely seems worth exploring. > > I am working on an implementation for NSS/Firefox and I know some > others are working on their own implementations, so hopefully we can > do some interop in Montreal. > > This is at a pretty early stage, so comments, questions, defect > reports welcome. Quick comments after flicking through the draft: - I'm not that fussed myself as to whether this uses a TXT or new RRTYPE. But if the latter would work, it seems better. - I didn't quite get what "all the domains" in 3.2 means. I guess if a client uses non-encrypted sni for one of those, it should still work, but I'm not clear if supporting esni for any domain means that the provider has to decrypt esni and then deal with successful decrypted sni values as if the client had sent sni in clear. A concern is requiring "all the domains" might make it hard to roll this out. - I guess some form(s) of key rollover will be needed, ut I'm not sure that not_before/not_after is the best way to do that. - The ESNIKeys structure generally seems a bit complicated, it might be better to aim for simplifying that and maybe making it more "zonefile friendly" (whether in a TXT RR or not). - It might be interesting to think about how this'd work for e.g. the IETF web site (where ietf.org is hosted locally but www.ietf.org is not), and for STARTTLS and MX RRs. That's probably ok, but I've not gotten it straight in my little head yet:-) - Would it make sense to include the innocuous dummy sni in the published RR, so that all clients use the same one and stand out that bit less? - 7.1 probably needs more work - I'm not sure that it's that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE, or a client application that knows the ESNIKeys, are most likely needed, but there's probably also some work to do to analyse the recursive to authoritative interactions to get the ESNIKeys even with DPRIVE. Lastly, the topic of whether or not to try address this problem is something that the WG has debated quite a bit, and IIRC the consensus after that debate was to do work on this (hence Christian's draft). So I don't see any need to debate whether or not to work on this is needed, and trying to re-open such a debate seems somewhat disruptive to me. It is entirely reasonable to consider what, if anything, widespread use of esni or other approaches might break though. But going back to all this "privacy at any cost" and "we're the enterprises" hyperbole is not at all helpful IMO, so I hope we don't have to suffer more rounds of that. But maybe that's inevitable with every iteration of attempts to improve privacy sadly;-( Cheers, S. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
