Re: [TLS] About encrypting SNI

[Andy Lutomirski <[e-mail]>]

On Wed, Apr 16, 2014 at 9:54 AM, Sniffen, Brian <[e-mail]> wrote:
>
> 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.

OK, I see the problem here.

Three possible solutions:

1. US government customers can just skip setting the DNSSEC option.
The same IP can host encrypted and unencrypted ClientHello users.

2. See if Curve25519 can be used in an encrypted ClientHello even with
FIPS certification.  The argument would be that this isn't really
cryptography, since it's just an additional layer on top of something
that's already certified.  I don't know whether this would fly.

3. Use something like Elligator.  This slows down the server a little
bit, since it will have to attempt to decrypt the ClientHello once for
each possible key, but there only really need to be two keys here.
This needs some padding trickery -- see below.

I don't think that Elligator works for NIST curves, but Elligator
Squared seems to.

I actually like #3, despite its complexity, because it allows the
entire encrypted ClientHello payload to be indistinguishable from
random.  This is a further argument for adding a little bit more
complexity to allow the rest of the handshake and the record layer to
be indistinguishable from random as well.  If nothing else, this will
make it much easier to extend things in the future, since middle boxes
that support TLS 1.3 won't be able to peek inside and screw up future
extensions.  IIUC the TLS 1.2 record layer is easily distinguishable
from random.


To keep everything on one page, here's the updated strawman:

DNS indicates, for each domain: (cryptosystem, public key,  guaranteed
TLS version)

Cryptosystems include:

Non-US-government-preferred choice: ECIES/Elligator on Curve25519,
with ChaCha20+Poly1305 AEAD.

US-governement-preferred choice: ECIES/Elligator Squared on P-256,
with AES-128-GCM.

If the client sees one of these DNS records, it sends:

ClientHello wrapper || f(a*G) || IV || AEAD(real ClientHello)

The function f is either Elligator 2 or Elligator Squared, as
appropriate.  If Elligator is being used, the client needs to try an
average of two times to get a value of a that works.  The client is
expected to include a padding extension in the real ClientHello with a
length calculated to hide the length of the SNI and the length of the
ECIES header.

The real ClientHello will contain a further extension that contains a
session key that will be used to encrypt the rest of the handshake and
indicates the cipher suite.  This cipher suite MUST be exactly the
same as the one used for the ClientHello (ChaCha20+Poly1305 or
AES-128-GCM, respectively).

The server tries to decrypt the ECIES payload with each of its keys.
This is quite fast, unless P-256 is supported, in which case it's
still not that bad.  It then proceeds exactly as it would if the real
ClientHello were sent in the clear.  In particular, it does not need
to remember the ECIES session key.

If the encrypted ServerHello extension is in use, then the ServerHello
and all remaining handshake messages are encrypted as specified.  This
happens regardless of whether the ClientHello is encrypted.


If TLS 1.3 plans on encrypting the ServerHello anyway in a manner that
is indistinguishable from random, then the extension part of this
strawman can be dropped.

I don't see why FIPS certifiers would object to the use of Elligator
Squared.  It's just a transformatoin of the bytes before they are sent
on the wire.

--Andy