As we discussed in Montreal, the ESNI draft doesn't seem to interact well with
origins which use multiple unrelated CDNs. While Section 7.2.2 says that the
scope of key sharing is between all hosts which can respond to a single IP
address, but the DNS lookup method described actually makes it a
I think perhaps we need to take a step back and explain something that might
not be well-known outside the community of CDN’s and their customers. It is
not uncommon for (admittedly larger) origins to use multiple CDN’s, and to
switch among them. This can be done on a per-request basis, because
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : The Datagram Transport Layer Security (DTLS) Protocol
Version 1.3
Authors : Eric Rescorla
Definitely agree this is something that needs to be addressed..
As Mike notes, the fundamental issue is that there are 2 pieces of
information that are statefully related (the key and address) but obtained
statelessly from each other and can therefore come from un-coordinated
sources. 2 CDNs are c
This line of commentary describes one instance of a more general situation
that is unrelated to the multi-provider case: what happens when you connect
to a server that doesn't know the ESNI key you're using? This can even
happen on a single provider due to DNS caching issues, for example.
The two
Thanks to those who contributed to the discussion on this topic over
the past two weeks. It led to useful insights and clarity around the
problem statement, desired use cases, and current state of this draft.
(Specifically, Viktor’s summary of the problem statement in [1] was
quite helpful and, abs
