Archive

> On 30 Apr 2021, at 09:28, Martin Duke <martin.h.duke@gmail.com> 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
> dns-privacy@ietf.org
> 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: marka@isc.org

Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)