On Wed, Feb 27, 2019 at 5:24 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hiya, > > First, I think both are wrong:-) > > If there are really different ESNI private value holders, > then each of those should provide separate ESNIKeys RR value > instances Yes, this is the idea and the set of all of those should be in the RRset > returned when the ESNIKeys are queried. > 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 for A or B as the case may be. So you're not going to get both ESNIKeys values. > Requiring different private value holders to find some > entity to wrap up all their crap into one single TLS blob > is not, IMO, a good design. > That's not the way this works. > On 27/02/2019 16:18, Christopher Wood wrote: > > Hi folks, > > > > Below are two PRs that seek to address the multi-CDN issue discussed > > on this list and in meetings: > > > > 1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136 > > 2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137 > > I'm not sure of the details of #137 but I think I prefer > that one a bit. I suspect either of them will be a pain to > code given how we'll be mixing names and addresses. > > #136 seems broken to me in that it gives the new AddressSet > invention priority over A/AAAA resolution. I think that'd > need much more justification as it essentially calls for > duplicating A/AAAA information over two administrative > domains which seems like a recipe for failure. > This is not correct for the reasons I indicated above. What happens is that the terminal CDN is responsible for publishing a record with its keys and its A/AAAA values. Indeed, the source of the problem we are trying to solve is that you might in successive resolutions get the CNAME for A and B, thus having a keys/A mismatch. > > My reason for preferring #137 is that (if I'm reading it > right, and I'm not sure!), it resolves a CNAME and then > compares the resulting A/AAAA acquired via normal CNAME > chasing to a mask from the ESNIKeys stuff. I think that > is a better approach than replicating A/AAAA values inside > a novel repetitive structure like ESNIKeys. > > Lastly, we will need to fix the TLS-developer-friendly > but DNS-admin-unfriendly ESNIKeys structure, [Citation needed] IMO the way to do > that is for each ESNI private value holder's stuff to be > a separate RR value in the RRset (and so each is likely a > separate stanza in a zone file). This seems to rest on the same misunderstanding of the scenario in question. -Ekr So in summary: > > - both are wrong:-) > - if I had to pick one to proceed with temporarily, > I'd go with #137 despite it being unclear > - I'd rather we fix the ESNIKeys to be DNS friendly > now too and not wait to have to inevitably fight > that battle later (but fight I will:-) > > Cheers, > S. > > > > > #136 implements the combined or stapled record approach discussed > > several times, most recently in [1]. It includes these via an ESNIKeys > > extension. #137 builds on this design with a mechanism that lets > > clients detect and recover from A/AAAA and ESNI mismatch (if desired). > > It is certainly more complex in several respects. A third variant, > > which is not (yet) in PR form, is a simplification of #137 wherein > > ESNIKeys addresses are only used as filters, instead of filters *or* > > complete addresses. > > > > We are asking for feedback on these PRs, as we would like to merge one > > of them for the next draft version. As #136 is simpler and permits > > extensibility, that is the current preference. > > > > Thanks in advance for your feedback. > > > > Best, > > Chris (no hat, on behalf of the authors) > > > > [1] > https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
