> On 30 Apr 2021, at 09:28, Martin Duke <[email protected]> wrote: > > 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?
On stream connections the client chooses a xid which is not currently in use. If you need more than 2^16 outstanding transactions at once you open a new stream. This has implications when forwarding signed UPDATE requests over a stream. For TSIG the xid of the forwarded request is independent of the incoming request. For SIG(0) you need to choose a stream where the xid is not currently in use. For UDP you do similar by choosing source ports. > _____________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
