Hiya, On 29/03/2019 21:44, Erik Nygren wrote: > 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 CONNECTi 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.
What do you mean by "canonical name"? (I wish we had a canonical set of definitions for the names involved in ESNI! Maybe I'll try craft some if nobody else has...) > 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). IMO there should be no extensions defined or needed for ESNIKeys - we have the RRTYPE and internal version number which should be enough. > 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.) That kind of thing and your points about the number of addresses involved make me wonder if #136 is really a viable approach. I'm generally not sure if the problem motivating #136 will turn out to be as bad as feared, esp. if the same DoH/DoT session can be used for the ESNIKeys and A/AAAA queries (though I'm also not sure if browsers could easily ensure that.) I guess maybe more testing may tell us more as DoH/DoT get better deployed. S. > > 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 >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
