Re: [TLS] DNS-based Encrypted SNI

[Kathleen Moriarty <[e-mail]>]

Sent from my mobile device

> On Jul 4, 2018, at 9:01 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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;-(

I’m also fine with the work going forward, however it was only in March that EKR assured people concerned that they don’t need to worry about SNI being encrypted repeating similar statements previously made to the same effect.  Meantime, he was working on such a solution.  People need warning to prepare for changes, not to be surprised by them after being told not to worry.  They may not have had a chance to think through how they might adapt.

Kathleen 

> 
> Cheers,
> S.
> 
> 
>> 
>> -Ekr
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> <0x5AB2FAF17B172BEA.asc>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls