Re: [TLS] About encrypting SNI

["Sniffen, Brian" <[e-mail]>]

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

> On Wed, Apr 16, 2014 at 9:15 AM, Brian Sniffen <[e-mail]> wrote:
>> Andy Lutomirski <[e-mail]> writes:
>> 
>>> 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.
>> 
>> Then the censor looks to see which key is used, yes?
>> 
> 
> The idea is that the same key would be used for hello encryption for
> all domains served by the same IP addresses.

Oh, I see.  But the US government customers want a key to a NIST scheme generated with Dual_EC, and the notional non-government entities want anything but that.

> Even if different keys were used, I'm not sure the censor can tell
> which.  I think that the particular public-key protocol I suggested
> doesn't leak any information about the public key used to a censor
> that doesn't know the private key, but I could be wrong.

But they want different protocols.  So we drift to having the censor-approved data on one IP, and the censor-opposed data on another IP.

I see the benefit of the wildcard proposal—it seems to help small users who don’t really get a say in their crypto, and just use example.tumblr.com and similar, where there’s a bunch of innocent social data mixed in with the politically interesting parts.  I don’t see how encrypted SNI helps preserve the privacy of the clients of a big web site against the adversaries I understand to oppose such.

-Brian