Re: [TLS] About encrypting SNI

[Eric Rescorla <[e-mail]>]

Andy,

This is an interesting idea and as you say, it has the virtue that it
doesn't require messing with the state machine at all. I have a few
comments:

1. You probably have to frame this as a ClientHello with some
opaque extensions which happen to be encrypted. The reason for
this is that there are stateful inspection devices which examine
data on port 443 and enforce that it looks like TLS. As these
 devices are associated with the client not the server, the server's
TLS 1.3 compatibility does not guarantee that the client will
in fact be able to send a non-TLS framed ClientHello.

2. It might (or might not) be easier to frame the advertised information
as a TLS cipher suite.

3. This only prevents downgrade attacks if the information
is secured via DNSSEC. There are intermediate elements which
damage enough of the DNS resolution process that they will
cause DNS signature failures even when the client knows that
the records are supposed to be signed. Hard-failing in these
cases will likely result in unacceptably high failure rates, but
if you don't hard fail, then a network-based downgrade to
unencrypted SNI is possible.


More generally, I note that a number of the suggestions that people
have provided here (yours, Watson's Rich's, my modification of Rich's)
have the common factor that they require the server to opt-in in some
way. This has the major advantage that it allows us to design a
mechanism which might be inconvenient for some network environments
because they can just not opt-in, as well as allowing out-of-band
delivery of some data in the DNS.

The disadvantage seems to be that a smaller fraction of sites will offer
encrypted SNI, which slightly paints
a target on them. I think that's probably OK, since no matter what mechanism
we use for encrypted SNI, it seems likely that an attacker will be able to
get a good handle on the virtual hosts served by a given site, and so
can use that to identify which sites he is interested in tracking even if
everyone were to use encrypted SNI. However, it's worth considering
and I'd love to hear from people who want encrypted SNI what they
think of this tradeoff.

-Ekr









On Tue, Apr 15, 2014 at 3:24 PM, Andy Lutomirski <[e-mail]>wrote:

> On 04/14/2014 10:21 PM, Watson Ladd wrote:
> > Now, the best mechanism I can think off would be to use DNS to preload
> > a per-IP SNI encryption key, or have the handshake optionally involve
> > getting one. But I still can't figure out how to authenticate the
> > gotten key without a lot of complexity. The best solution is for the
> > client and server to do a DH, then pass the desired website (which
> > might get you investigated when the initial handshake is intercepted),
> > and have that cert sign the handled DH, then go back and do a TLS
> > connection. Ugh.
>
> What if it were an opt-in thing?  A hypothetical DANE extension could
> associate with each domain a tuple (ClientHello-protection public key,
> TLS version guaranteed to be supported).  Clients could resolve that
> essentially for free as long as they're already querying DNS, and this
> could prevent downgrade attacks and give an efficient way to encrypt the
> entire ClientHello.
>
> Note that there's no reason that the public key in here should have
> anything to do with the eventual TLS handshake.  In fact, I would argue
> that it should be completely independent, so that large-scale load
> balancers could strip the encryption off the ClientHello and hand the
> connection off to something else that knows the real key.
>
> As a concrete algorithm, the extra DNS information could be 36 bytes: 34
> for ("Curve25519/ElGamal + AES-128-GCM" || "B = b*G") and 2 for "TLS
> 1.3" in some suitable format.  If such a record exists, then the client
> starts the connection with something like "Encrypted Hello" || a*G || IV
> || AES-128-GCM(a*B, IV, ClientHello).
>
> Arguably, the rest of the handshake should be encrypted with the same
> key.  The only reason I suggested this particular public-key
> cryptosystem is because it makes it easy to encrypt the reply.
>
> There's a weak argument to be made for arranging for the actual
> encrypted ClientHello to be indistinguishable from random by anyone who
> doesn't know the private key.  This ought to be straightforward using
> Elligator.  Off the top of my head, it sounds cute, but I don't really
> see a benefit.
>
> The TLS version is to prevent this thing from being downgraded away: if
> the server tries to claim that it only speaks TLS 1.2, but the DNS
> record said that the server supports TLS 1.3, then the client aborts.
>
> This isn't directly per-IP, but a sensible server deployment should use
> the same exact data in DNS for everything it hosts on the same IP.
>
> This adds no round-trips.  It costs a few random bytes, two
> multiplications, and an AEAD invocation on the client, and it costs one
> multiplication and an AEAD invocation on the server.
>
> It adds very little protocol complexity: the encrypted ClientHello is
> exactly the same thing as a regular ClientHello but with an extra layer
> of encryption on top.
>
> --Andy
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>