Stephen, there are a couple complicating factors here where I think we all have varying knowledge gaps.
* There are two major ways of pointing to a CDN: Direct A/AAAA records and CNAMEs. The easiest way to handle key update complexities on the part of the CDN(s) is simply to CNAME the ESNI query for your domain to their ESNI record, but you can certainly directly host your CDN’s keys in your domain if you prefer. Nothing should preclude that. * The issue we’re trying to address is when the ESNI record and the A/AAAA record follow different CNAME chains and you get the records from different hosts. Of course, if we move to an ESNI RRType with the same hostname (see #105), there’s hopefully a single CNAME chain that gets cached at the resolver and used when looking up both queries. If they remain separate hostnames, it seems like it gets much easier for them to diverge. * It’s my understanding that DNSsec doesn’t play well with returning a subset of all extant RRs for a given name+type. However, some CDNs return DNS results tailored to the user’s location; the load-balancing servers will (in some cases) return CNAMEs to different targets based on the desired traffic share. That’s not a behavior that maps well to DNSsec as I understand it. You mention DNSsec signing your domain as part of why you have issues with the proposal, but I think this is an open issue beyond ESNI or these PRs. Maybe someone better-steeped in DNS/DNSsec can help us figure out how all that should work, and I agree with you that there are definitely bumps here we need to iron out – maybe those are just questions to answer, or maybe changes to the structure of the record are warranted. However, these PRs are primarily about what information should be in these records and how clients make use of it. I disagree with you that we have to resolve both questions at the same time. Let’s agree on content first, and spent some time separately with DNS folks to see whether the content can be more pleasantly arranged. -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Stephen Farrell Sent: Thursday, February 28, 2019 2:50 AM To: Eric Rescorla <e...@rtfm.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Two Multi-CDN proposals Hiya, On 28/02/2019 02:40, Eric Rescorla wrote: > On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell > <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> > wrote: > >> >> Hiya, >> >> On 28/02/2019 01:41, Eric Rescorla wrote: >>> I think you're misunderstanding the scenario here: we have two CDNs >>> A and B, and some switching service in front, so that when you >>> lookup >> example.com, >>> you get a CNAME to A or B, and then you get the ESNIKeySet >> >> (ESNIKeySet is a type you've just invented I guess?) >> > > No. I forgot it was named ESNIKeys > Phew:-) >>> for A or B as >>> the case may be. So you're not going to get both ESNIKeys values. >> >> Yes, that's not the model I had in mind. I don't recall that having >> been written down but maybe I missed it. (Where should I look?) >> > > I believe this was discussed in Bangkok during the discussion of > problems with the current structure. FWIW, I didn't take from that discussion that we only want that model to be supported, but it may have passed me by if that was stated. >> The model I had in mind was where the hidden site has it's own DNS >> operator but >1 CDN/front-site with each of those having a private >> ESNI value. (And if there's some front-end DNS cleverness, it'd kick >> in when the CNAME from #137 is being chased down.) >> > > I don't see how this is conflicts with what I said above, as that > server still needs to ensure consistency. I don't think mine conflicts with the model you describe, but I do think it has different consequences for how we ought structure the ESNIKeys stuff. To be more specific, say in my model I have example.com and want to see ESNI used for www.example.com<http://www.example.com> and I publish the zone for example.com including ESNIKeys. Now I want browsers to be able to use either cdn1.example or cdn2.example to front for www.example.com<http://www.example.com> where those are independent CDNs. So I need to update my DNS zone periodically whenever one or other CDN changes their ESNI public key share. In my tiny little case doing this for a few domains, I already have a small infrastructure that allows me to do that kind of thing because of the need for regular DNSSEC re-signing. (Mine currently works at a weekly or daily cadence, but doing it hourly would be fine.) I'd like to do that via a simple update to my zone files without having to unpack and re-pack the data structures I get from cdn1 or cdn2. Now sure, I could write a new tool to munge together what I get from the CDNs but that's more work (that could go wrong) and doesn't match my current work flows. And I suspect others may operate similarly. That's what leads me to think that we'd be better off to have multi-valued answers when a browser looks up the RRset at _esni.www.example.com with each separate value matching one ESNI public share (or one CDN, though I'd argue for one share per zone file stanza). I don't think that conflicts with your model where _esni.www.example.com is one or another CNAME at a given moment but it does differ from it. There is however some dependency on #137 to get what I want I guess using the host_pointer to get the privacy benefit of using a CDN. I guess I might need to publish yet another ESNI public share that matches the private available at the A/AAAA of www.example.com<http://www.example.com> as well as those from the CDN even though that may get me less privacy benefit compared to browsers who go to cdn1 or cdn2. (It's possible that I'm reading #137 wrong though, but I read it as supporting the kind of setup I describe here.) > In any case, the model I am describing has a consistency problem which > needs to be addressed. >> PS: I nonetheless maintain my points about the current ESNIKeys >> structure - it's over generic and over complex and these PRs can only >> make that worse:-) >> > > Yes, I am aware this is your opinion, but I don't agree. Fair enough:-) Personally I think that if we support the kind of model above, such simplifications may well naturally fall out of that work but we'll see I guess. For example, I think that'd allow re-structuring the ESNIKeys thing so the host_pointer in #137 no longer needs to be an extension and hence we don't need the concept of mandatory/critical extensions at all. Cheers, S. > > -Ekr >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
