On Thu, Feb 28, 2019 at 5:51 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hiya, > > On 28/02/2019 13:12, Eric Rescorla wrote: > >> 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. > > > > Seems one of us is confused then, likely me:-) > > Lemme try clarify it out this way: > > $ dig +short txt _esni.cloudflare.com > "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT > C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX > HPm0AAAAABce8/QAAA=" > > That's one encoded ESNIKeys value accessed just now. > > The ietf.org domain has two TXT RR values, (actual content > elided below for brevity) so I get: > > $ dig +short txt ietf.org > "somegooglestuff" > "lotsofspfstuff" > > What I'd like to see for my earlier example.com case would > be like: > > $ dig +short txt _esni.www.example.com > "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT > C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX > HPm0AAAAABce8/QAAA=" > "/wHHBBOoACQAHQAg4YSfjSyJPNr1z3F8KqzB > NBnMejim0mJZaPmria3XsicAAhMBAQQAAAAAW > 9pQEAAAAABb4jkQAAA=" > > Where the first is supplied to me by cdn1.example and the > second is from cdn2.example. > > And have browsers and other ESNI clients be able to handle > that, picking whatever they consider the best of the usable > options presented. > My understanding is that this is problematic for DNS reasons, namely that you are supposed to concatenate the records, and that we definitely need a way to go above 255 bytes. But I'm no DNS expert and if there's a way to have both of these, then I have no problem with it. (And assuming we are: I'd subsequently suggest we can > simplify ESNIKeys so that it just has one KeyShareEntry per > RR value and not a list of those, since multiples for one > CDN or many CDNs can be handled already as above. Yes, I believe you've made this suggestion before, and I opposed it for the same reason I oppose it now. While technically possible, it requires you to duplicate everything else in the entry, which is bad, and worse the more other stuff you put in the record (for instance, the public name). -Ekr I think > making that change, and perhaps other simplifying changes, > at the same time as moving from TXT to a new RRTYPE would > be a fine thing, but there's no pressing need to make all > those changes for the -03 draft or in #137 though, I'd be > happy if we're heading there a little later.) > > Cheers, > S. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
