Re: [TLS] About encrypting SNI

[Andy Lutomirski <[e-mail]>]

On Wed, Apr 16, 2014 at 11:56 AM, Erik Nygren <[e-mail]> wrote:
> If we do anything with DNS, we need to be very conscious that individual
> records change asynchronously from other records.  For example, we can't
> assume that an A/AAAA record and a DANE record refer to the same operator
> (webserver, hosting provider, CDN, etc).   In order for anything along these
> lines to be deployable, it must be possible for everything associated with a
> particular name->service binding to change together.  In addition, browser
> vendors are extremely wary of doing extra DNS lookups synchronous to a
> request which is one reason that SRV records aren't in-use today for
> HTTP(S).

You can hack around this by temporarily turning off hello encryption
when switching providers.  This is unfortunate, though.

>
> After thinking about this some, if we are looking towards a future world
> where additional DNS security and privacy has been added, a new "service
> binding" record type (I'll call it a "B-record") might help partially
> address a number of these issues and raise the bar a little about SNI
> privacy.  The B-record would glue together information needed for
> establishing a connection (and provide a client with a number of options to
> choose from).  For example:
>
>      _https._b.www.example.com B  "AAAA=2001::abcd, port=443, alpn=h2s,
> handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335,
> pri=5, dane_cert_name=version83.ca.example.com"
>      _https._b.www.example.com B  "A=1.2.3.4, port=443, alpn=h2s,
> handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335,
> pri=5,  dane_cert_name=version83.ca.example.com"
>      _https._b.www.example.com B  "A=1.2.3.5, port=443, alpn=h1s,
> handshake_ecdhe_key=438nkgj8utjs89we0t8tjer, handshake_token=asdjhk887,
> pri=3,  dane_cert_name=version82.ca.example.com"
>
> Defines a set of HTTPS service bindings for a few sets of IP addresses with
> different ALPN settings.
>
> In the above, the handshake_ecdhe_key is the public part of the server key
> to encrypt the handshake (including SNI to and the handshake_token is the
> "opaque" value from ekr's flows proposal.  Clients could select between
> which of them they'd use based on their ALPN support.
>
> At least for HTTP(S), something like this might be more deployable than
> current options.
>
> Note that the handshake_token (sent in the clear in the TLS handshake like
> the "opaque" value) will leak information to passive attackers who are
> building up correlation tables.

I'm not sure exactly what you mean by handshake_token.  Do you mean
the anti-replay token?

The handshake token as a way of identifying the service binding in use
seems problematic to me.  Wouldn't it be better to just leave it out
entirely?  As long as each IP only accepts one or two handshake keys,
then figuring out which one is in use by trial decryption should be
fine.  I think that something is wrong if you have an IP with lots of
handshake keys.

Realistically, you may need up to four handshake keys: old FIPS, new
FIPS, old non-FIPS, new non-FIPS.

>
> Also if the key is used *only* for the handshake, it's not clear that this
> is any worse against active attackers even if DNSSEC is not used than the
> "new flows" proposal.  (In both cases a MitM can provide an alternate
> handshake key or build up a table of ids to SNIs.)  Clearly DNSSEC would
> need to be used for *every* step before DANE could be used, however.
>
>
> I think the question from above arises of whether it is worth doing all of
> the engineering work here if there's still no fundamental way to guard
> against active attackers or resourceful passive attackers.  Some of this
> will come down to trade-offs.

I think my approach is actually secure against active attack, so long
as the client is willing to fail if DNSSEC validation fails.  Your
idea of B records could be as the DNS component.

--Andy

P.S. As a side note, here's a tweak to mine: the DNS-encoded key
should include the length of the maximum overhead that any handshake
cipher suite imposes to make the padding calculation easier.  That
adds one byte or so.