Re: [TLS] Alternative ESNI?

[Nico Williams <[e-mail]>]

On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> On Fri, Dec 14, 2018 at 6:54 PM Nico Williams <[e-mail]> wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on their behalf.
> >
> > Also, while we're at it, I'd like to note that SNI is not the only thing
> > requiring privacy protection from the client.  There's also the PSK
> > identity payload for non-resumption PSKs...  Not as important as SNI,
> > perhaps, nonetheless I think we should maximize privacy, else we'll be
> > engaging in repeated encrypted-{fill-in-the-blank} exercises.
> >
> > Our proposal makes DNS optional (for co-tenancy fronting discovery) and
> > DNSSEC not necessary.
> >
> > The basic idea is to use a HelloRetryRequest to make a handshake traffic
> > secret available to the client for it to use in its subsequent hanshake
> > messages.  This form is susceptible to an SNI disclosure active attack
> > -- same as the current ESNI proposal w/o DNSSEC.  This variant adds one
> > round-trip to full handshakes.
> >
> 
> We looked at this class of design during the initial work on TLS 1.3
> because (a) it has trivial active attacks, as you note and (b) we
> don't want people to have to accept an extra round trip in order to
> get ESNI, because that's a major disincentive to doing it.

One of the two has no active attack, and the extra round trip is already
possible due to the existing HelloRetryRequest flow.  The variant that
is resistant to active attack has a worst case additional round-trip,
but again, only on initial handshake.

BTW, the flows I presented have no multi-CDN keyshare private key
distribution issues because there are no keyshares to publish in the
DNS.

> WRT to the active attack point, DNSSEC isn't necessary with the
> current ESNI design. What's necessary is that the client be able to
> get the ESNIKeys record (and the A/AAAA records) securely wrt to the
> attacker trying to get the SNI.  However, in a large number of cases
> (e.g., an attacker on your local network, there are non-DNSSEC ways of
> obtaining this property, such as using DoH.  In addition, if the

DoH?

> attacker controls DNS (or generally can observe DNS traffic) then
> getting the SNI encryption key securely isn't sufficient because the
> attacker can just learn the domain name from the DNS lookup (or return
> a unique IP for each query and then use that to look up the SNI from
> the IP).

Sure.  DPRIV is still needed, no doubt.

> > We can then optionally piggy-back the server's Certificate and
> > CertificateVerify along with the HelloRetryRequest (provided the
> > client's initial key_share is acceptable to the server), and now we have
> > authenticated the server under its fronted name, which means there is no
> > active attack on the ESNI.  This still only adds just the one round-trip
> > to full handshakes.  And look ma', now w/ no DNSSEC requirement to avoid
> > active attacks.
> >
> 
> This seems like a more invasive version of what David Benjamin et al.
> proposed the other day, just without the ESNI key at all. I don't
> think this is an acceptable general solution for latency reasons (as
> opposed to fallback), and of course you still need some way to

Again, it's comparable to the existing HelloRequestRetry flow case.

> securely obtain the domain name you put in the SNI, and if this isn't
> done with DNS, then you end up with a situation where very few people
> use ESNI and so you stick out.

Granted.  But not having to coordinate privte keys for the keyshares to
be published in the DNS seems like a very big win.

Nico
-- 

Nico
--