Hi Sara, > > > - Please explicitly state that, IIUC, these XoT connections use the DoT > ALPN. > > That is not actually the case, but even so, we should probably add text to > clarify the matter. > > An early version of this specification proposed a XoT specific ALPN in > order to distinguish this from a connection intended to perform recursive > to authoritative DoT (often called ADoT). ADoT is not yet specified, but is > the subject of ongoing discussions in DPRIVE. The working group rejected > this idea for XoT and switched to the current spec which does not use an > ALPN at all. Note that one of the proposals for how DoT support by > authoritatives for ADoT would be signalled does use the DoT ALPN. >
Then I guess I'm not sure how you're going to demultiplex with other traffic. Are you totally reliant on the port? > > > > > - There ought to be a warning somewhere that mTLS verifies that the CA > has > > verified identity, while IP ACLs merely prove that the bearer can > observe the > > path to the address. The former is much stronger than the latter, unless > there > > are more mechanisms built into the ACL than are obvious from the text > here. > > Agreed, and this follows up on a previous similar comment. We could add > text to section 10.4 at the end of the second paragraph along the lines: > > “Is should also be noted that mTLS provides a stronger authentication of > the client than an IP ACL because the former is based directly on a > verified identity.” > > We could also add something to the security considerations but I struggled > to find a good reference for the issues with IP address validation? > I don't have a reference, but something like your proposal is good enough for me. > > > > > - Please educate me: from my skim of the RFCs AXFR has message IDs, but > IFXR > > does not. So how would a client demux IFXR responses? > > IXFRs do use message IDs - they are defined as just ’normal’ DNS messages > with the IXFR query type in RFC1995 and so inherit that requirement > (although on re-reading it isn’t _explicitly_ described there). In that > original specification IXFRs can use UDP (or TCP) and so would definitely > require message IDs for UDP. I’m not aware of any implementation that omits > message IDs for IXFRs. Is there something else you saw that lead you to > think otherwise? > > I think the confusion could arise because in RFC1034/1035 only AXFR was > defined and was required to use TCP, in contrast to other DNS queries at > that time. The description of message exchange is vague and apparently lead > to some implementations doing only a single AXFR transaction per TCP > connection and therefore omitting the transaction ID. The 2010 update to > the AXFR specification (RFC5936) notes and corrects this confusion in > section 4.1. > This is as simple as me grepping for "message ID" in the IFXR spec. But if these do exist, what protections do you need against ID collisions in Section 7.3.2?
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
