Re: [TLS] DNS-based Encrypted SNI

[Stephen Farrell <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>