Re: [TLS] ESNIKeys over complex

[Eric Rescorla <[e-mail]>]

On Tue, Nov 20, 2018 at 7:40 PM Salz, Rich <[e-mail]> wrote:

>
>    - No, I don't think so. The server might choose to not support one of
>    the TLS 1.3 ciphers, for instance. And even if that weren't true, how would
>    we add new ciphers?
>
>
>
> Standard TLS negotiation. I don’t see that we need to specify ciphers at
> the DNS layer. A client with new ciphers will add it in the hello message
> and the server will pick one it supports.  It seems complex and fragile
> (keeping the server cipher config, not just the fronted hosts, in sync with
> DNS).
>

I'm sorry, I'm not quite following. In this draft, ESNI ciphers are
orthogonal to the ciphers used to encrypt the TLS records.This is perhaps
easier to see in a split configuration, where (for instance) the
client-facing server might support only AES-128-GCM and the back-end server
might support only ChaCha/Poly1305. As you say, the negotiation works well
for the TLS records, but that doesn't influence the ESNI encryption cipher
suite selection (because that happens before the Hello exchange). So, if we
don't provide a list of the ESNI ciphers in the ESNIKeys record, then we
are effectively creating a fixed list.

Am I missing something here?

-Ekr


>