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 and the set of all of those should be in the RRset returned when the ESNIKeys are queried. 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 said, we can fix that later I guess, even though we will have to fix it sometime. (Fixing it now would be better!) So I regard these ESNIKeys syntax decisions as only holding temporarily. 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. If #137 is adding mandatory extensions that are analogous to X.509 extension criticality, then I think that's an error. Despite good arguments, that has not worked out well and this seems like the same mistake. (But as stated above, I think all syntax here is temporary until we've made it DNS admin friendly which it is not.) 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, so why not do that now too, as we're modifying it? 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). I also think if we did that we'd be able to simplify the ESNIKeys structure a good bit all of which should lead to more robust and simpler code. My current code for handling ESNIKeys is very complex and long even though I've ignored the supposed ways in which things can be extended - were I to have to add real extension handling, it'd be even worse. Changing to >1 RR value in the answer could make all this an awful lot simpler and much better match the multi-CDN (or more properly multi-private-value) scenarios. 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 >
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
