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