On Tue, Nov 20, 2018 at 7:40 PM Salz, Rich <rs...@akamai.com> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
