Re: [TLS] More issues with current ESNIKEYS DNS approach

[Stephen Farrell <[e-mail]>]

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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>