Re: [TLS] About encrypting SNI

[Erik Nygren <[e-mail]>]

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).

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.

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.

        Erik









On Wed, Apr 16, 2014 at 10:39 AM, Andy Lutomirski <[e-mail]>wrote:

> On Wed, Apr 16, 2014 at 7:32 AM, Brian Sniffen <[e-mail]>
> wrote:
> >> Furthermore, no offence to Rich, but I suspect if you told him "We'll
> >> build the DNS subdomain forwarding, and you can use that or just not
> >> encrypted SNI", he will choose not to use it. Maybe I'm wrong, but
> >> since he argued against it initially, I'll make the leap.  So making
> >> it opt-in seems to be as equivalent to building an optional feature
> >> that almost no one will use from the beginning.
> >
> > Yes: we will not use encrypted SNI.  We can't.  We need to put thousands
> > of HTTP hosts with incompatible crypto requirements on each IP address.
> > Per-IP keys don't help us very much.
>
> Would a protocol along the lines of my strawman work for you?  I
> explicitly did not require that the eventual cipher suite match for
> different SNI values.  I even made it possible to for whatever
> receives the initial SSL connection to strip the SNI encryption and
> hand the connection of to something else, without sharing any
> long-term secrets between the machines in question.
>
> --Andy
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>