Following the discussion this week I realized some other major issues we'll
need to make sure we cover:
1) Handling proxies here is going to be tricky. The CONNECT generally
needs to specify the hostname which needs to go to the server which has the
ESNI key for what gets sent in the TLS handshake. IPs don't come into play
here at all. The only thing I can think of for handling this is to pass
the canonical name to the CONNECT when using a proxy, and making sure that
the canonical name is specific to a CDN. There may be some related issues
in non-proxy environments.
2) The extension model breaks down if not all CDNs send it as mandatory.
In the hallway, Chris suggested we could require at least one extension be
manditory in any ESNIKey record in DNS. There could be a bunch of similar
corner cases. This issue also applies to switching off of using ESNIKeys
(eg, if there had been no extension included).
3) Trusting A and AAAA records from the EDNSKeys is going to break
environments relying on /etc/resolv.conf for spoofing to staging or other
testing environments. (Services and Support staff will likely be unhappy
as they do this all the time.)
On Sat, Mar 9, 2019 at 9:08 PM Christopher Wood <christopherwoo...@gmail.com>
wrote:
> >> i'd also like to hear from CDNs about whether their address ranges
> >> are really small enough to not make the list of ranges prohobitive.
>
At least for one CDN, there are tens to hundreds of possible A/AAAA records
that could be used in a given cluster, and then many thousands of
clusters. Especially on IPv4 this space is not dense as some comes from
local provider space. (The net result for each is far more IPv4 and IPv6
addresses than can be enumerated reasonably.)
Some additional minor issues we'll want to address or specify, regardless,
if we take this path:
* We'll want to make sure to specify that clients must round-robin or
permute the A and AAAA records included in the address list. Typically
most recursive and/or stub resolvers handle this, but since it's all in one
RR and not an RRSET it will be on clients to do this properly.
* We may wish to provide guidance on how to handle A vs AAAA (eg, reference
RFC 8305). One thing that clients may lose out on is support features
provided by the OS, such as those which sort results based on past
knowledge about RTT and the like.
I'm increasingly thinking that while we may wish to define a
general-purpose ESNIKEY record for use by generic applications, we may wish
to define application-protocol specific use-cases and bindings for some of
the most persnickety applications. For example, an HTTP-specific "HTTPS"
record that combined ALTSVC, ESNIKEY, and "ANAME" style information may
solve a bunch of these issues together. I've been talking to some folks
and am tempted to try writing up a draft on this. (Mail might be another
case that will just want its own binding...)
Erik
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
