On Fri, Dec 14, 2018 at 9:48 PM Nico Williams <n...@cryptonector.com> wrote:
> On Fri, Dec 14, 2018 at 08:01:35PM -0800, Eric Rescorla wrote:
> > On Fri, Dec 14, 2018 at 6:54 PM Nico Williams <n...@cryptonector.com>
> 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
It only doesn't have an active attack because you have assumed away
some method of distributing the name to put in the SNI in the clear.
and the extra round trip is already
> possible due to the existing HelloRetryRequest flow.
Yes, but we expect that HRR is going to be quite rare. If it's not,
other things have generally gone wrong.
BTW, the flows I presented have no multi-CDN keyshare private key
> distribution issues because there are no keyshares to publish in the
> DNS.
>
No, but they have similar problems in terms of coordinating the SNI
you put in the clear. Consider the case where domain X desires to
use ESNI and is hosted on CDN 1, which also hosts domains A, B, and
C, and CDN 2, which also hosts domains U, V, and W. What domain
does it put in the cleartext version of the SNI?
> > 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?
>
DNS over HTTPS.
> > 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.
>
A case which we try to avoid.
> > 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.
>
As noted above, I don't think you're meaningfully avoiding this,
-Ekr
> Nico
> --
>
> Nico
> --
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
