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

[Martin Duke <[e-mail]>]

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?