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 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.
And if the client already knows about the co-tenancy of the fronting
and desired servers, then no DNS lookups are needed to discover it.
E.g., dissidents might learn this by word of mouth.
The second variant can, sadly, add an extra round-trip when the server
finds the client's initial key_share unacceptable.
As to resumption, the real SNI should be the one from the original full
handshake, and the SNI in the resumption should be the fronting
service's name. Resumption retains the same latency as in RFC 8446.
Below are the flows for the three cases, all of these being full
handshakes. Naturally, these should be read after first reading figure
2 from RFC 8446.
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
{EncryptedExtensions}
+ key_share -------->
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 1: Alternative ESNI w/o active protection
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions*}
{Certificate}
{CertificateVerify}
<-------- {HelloRetryRequest}
ClientHello
+ key_share
{EncryptedExtensions} -------->
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: Alternative ESNI w/ active protection
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions*}
{Certificate}
{CertificateVerify}
<-------- {HelloRetryRequest}
ClientHello
+ key_share
{EncryptedExtensions} -------->
{EncryptedExtensions}
{CertificateRequest*}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Alternative ESNI w/ active protection,
with worst-case latency
Thoughts? Is this horrible somehow? Has this been discussed and
discarded for some reason?
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
