Re: [TLS] About encrypting SNI

[Andy Lutomirski <[e-mail]>]

On Mon, May 12, 2014 at 5:38 PM, Nico Williams <[e-mail]> wrote:
> On Wed, Apr 16, 2014 at 8:53 AM, Tom Ritter <[e-mail]> wrote:
>> ....But... There once was a thing called DNSSEC Stapled Certs
>> (https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a
>> SSL certificate had a chain of DNSSEC signatures in it, validating it
>> via DANE (or at that time, a DANE-like mechanism.)  It violates a
>
> I've been thinking of this for a while...
>
>> layering principal that people hold dearly, shoving DNS information in
>> other corners it shouldn't be.  But I think it would be necessary for
>> the wildcard approach to be reliable for clients like browsers.
>
> Layers aren't pure though.  Some things show through the various
> layers' interfaces, sometimes several layers through.
>
> For example, many apps have to deal with all of DNS and TCP/IP, with
> IP addresses and TCP port numbers used together in socket APIs.  It
> might have been a lot better if the sockets APIs had deal with
> hostnames from the start, but here we are.  Abstractions are leaky.
>
> Now in this case I think saving a client a number of DNSSEC lookups
> could be convenient.  We should -of course- make sure that this works
> out securely -- we don't want to end up with a cache poisoning attack
> here.

I think that we could get a lot of mileage out of the idea of having
some kind of DNSSEC-backed service binding.  There are all kinds of
interesting fields we could stick in there if we had such a thing and,
if we do it right, clients that can't read the service binding would
just fall back to normal (plaintext SNI, PKIX) TLS.

I'm planning on talking about this at the meeting this week.

--Andy