Re: [TLS] About encrypting SNI

[Erik Nygren <[e-mail]>]

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

      Erik