On Thu, Feb 28, 2019 at 2:50 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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. > No, it's merely the most challenging. > >> 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. > The vast majority of people have someone else manage their DNS, so I'm sure some others do, but I doubt many. > 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 really understand your point, because this *is* the expected design. > >> 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. > Well, obviously if you bake all the functionality into the record from the start, you won't need extensions, mandatory or otherwise. But I don't think this piece of functionality is well enough understood to tdo that with. -Ekr > Cheers, > S. > > > > > > > -Ekr > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
