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 > > 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. > 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. 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. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
