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 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/ 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
> 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/ 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 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 (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
