> On 23 Apr 2021, at 21:54, Martin Duke via Datatracker <[email protected]> > wrote: > > Martin Duke has entered the following ballot position for > draft-ietf-dprive-xfr-over-tls-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > > > ---------------------------------------------------------------------- > COMMENT: > ———————————————————————————————————
Martin, Many thanks for the review. > > - 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. > > - 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? > > - 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. Best regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
