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.
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 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).
> 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 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.
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
