Ah OK, now that I see that the Message ID is a field in the DNS header, it's clear to me these won't collide.
Regarding ALPN: I gather that IFXR/AFXR is distinguishable from regular DoT on the wire, so that it would be sufficient (and preferred) to simply use the DoT ALPN. On Thu, Apr 29, 2021 at 5:30 PM Mark Andrews <[email protected]> wrote: > > > > 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
