Re: [TLS] About encrypting SNI

[Andy Lutomirski <[e-mail]>]

On Wed, Apr 16, 2014 at 7:46 PM, Erik Nygren <[e-mail]> wrote:
>
> On Wed, Apr 16, 2014 at 3:09 PM, Andy Lutomirski <[e-mail]>
> wrote:
>>
>> 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.
>
>
> In my experience, anything of this form not designed to be easy to operate,
> reliably support rotation, and robustly move between providers is likely to
> fail to be deployable.  Errors in this world seems to be a top cause of
> outages and this sort of thing can be very hard to reason about.  Sadly,
> anything that requires "hack around" as part of its normal operating regime
> just isn't going to work.
>

I agree.  Using "bindings" as you suggested is better.  It also adds
no extra round trips.

>
>
>> 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.
>
>
> Perhaps handshake_key_label would have been a better term.
> I was referring to what is in PredictedParameters.server_key_label in ekr's
> tls13-new-flows
> (which has the same problem if not handled properly, and even if used
> properly still
> has risks here which may not have good answers).
>
> There are plenty of valid scenarios where you may need considerably more
> than four.
> An example given earlier on the list is for VM/cloud hosting providers who
> need to demultiplex
> from a small number of IPv4 addresses to different backend servers being run
> by different
> entities without mutual trust, each of which having independent different
> sets of keys.
>

You still only need four.  Remember that my ClientHello key is
completely independent of the key associated with the server
certificate, and that it can be stripped.

Suppose that there are a thousand domains, all sharing a few IPv4
addresses, but actually served by 100 mutually distrustful backend
servers.  You would configure all thousand domains to share the same
ClientHello key.  The devices that own the IPv4 addresses would know
the private key.  Whenever a connection comes in, they decrypt the
ClientHello, read the SNI, and forward the decrypted ClientHello to
the appropriate backend.  That backend server does not know the
ClientHello private key, but it doesn't need to.  Similarly, the thing
that owns the IPv4 address does not need to know the backend server's
private key.

So you still only need one or two keys under normal circumstances and
two or four while rotating ClientHello keys.

--Andy