Re: [TLS] DNS-based Encrypted SNI

[Eric Rescorla <[e-mail]>]

Stephen,

Thanks for your comments.

On Wed, Jul 4, 2018 at 6: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 think the answer is "a lot". Basically, the entire reasoning here is that
you can convert a lot of people at once. If you can't, then I don't think
this is a viable option.



- 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.
>

Yeah, this is badly written. It just means "all the ESNI-supporting
domains". But as I said, if you host 50 domains and you only
turn on ESNI for one, it's kind of pointless.



- 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).
>

The structure started a bit simpler and got new features to
deal with new issues. Specifically:

- The checksum is intended to deal with corruption
- The keys and cipher suites seem kind of mandatory
- The padded length is needed to tell the client how much to
  pad. Though I guess we could always pad to 260. If you don't
  pad at all, it doesn't work.
- I think it's clear what not_before and not_after are for. If you have
  more concrete feedback about better ways to do that, we'd welcome
  this.
- Extensions is just there because we're trying to be safe.

FWIW, this actually is pretty friendly because we b64-encode
(thus making the internal structure opaque to DNS). Removing
things won't make it much smaller because a big chunk of
the data is in the keys. For instance, in my implementation,
the object is 70 bytes long and 34 bytes of that is key (X25519)
and 8 bytes is cipher suite (each of these has 2 bytes of length).




- 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:-)
>

I don't think we're assuming it applies to subdomains.



> - 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?
>

We actually had an "alt-svc" thing in here for that and removed
it at the last minute. I'd welcome input on the best thing here.



> - 7.1 probably needs more work -


The whole draft 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.
>

"OK" might not have been the best choice of words. I think this actually
contains two arguments:

1. You don't need DNSSEC.
2. It doesn't make matters worse to do this over unencrypted DNS (i.e.,
you're already
in trouble).

That said, it also doesn't add much value to do ESNI if the attacker
controls your DNS, and in Firefox we're looking initially at just doing it
when DoH is in use.



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).
>

Thanks for making this point. My understanding was that we had WG consensus
to protect SNI. Of course, it may be the case that the WG doesn't like this
solution for one reason or another -- including potentially that it has an
especially bad impact on enterprise deployments compared to other
approaches -- but that seems like a different thing than saying we
shouldn't try to protect SNI at all.

-Ekr



> 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
> >
>