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

[Martin Duke <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> > On 30 Apr 2021, at 09:28, Martin Duke <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
>