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

Mark Andrews <> Fri, 30 April 2021 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5017E3A19B1; Thu, 29 Apr 2021 17:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=gczYZI7g; dkim=pass (1024-bit key) header.b=Dq841ttN
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BSbJ_arrp3qB; Thu, 29 Apr 2021 17:30:25 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FD313A19AE; Thu, 29 Apr 2021 17:30:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 926CC3AB02A; Fri, 30 Apr 2021 00:30:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1619742623; bh=ep1oUgqw0m6A/5Lf1JedWhXpXnt3xjKgGJpkZgLWW7E=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gczYZI7gnCtOpEJGS9xk4b6gkZUxf0s7iZmf7SUjsi5MA8d+HL79NmcfHugTbVFFt hQLAdeTyhc+kI+ac+Hyav8DyOKDeCZir3Yk5E34eDm/0kPLOqAvnFzIYDmCN1t+HOm ilWeZN9svLdwSzkoQpfZVMFHjJvvujA8mJunyyLg=
Received: from (localhost.localdomain []) by (Postfix) with ESMTPS id 6F757160085; Fri, 30 Apr 2021 00:30:23 +0000 (UTC)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 3427F160084; Fri, 30 Apr 2021 00:30:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 3427F160084
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1619742623; bh=v3aJAXAQivjk2LFnd6hBRsKj4mDpmxB+mo2Tqa52RSQ=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=Dq841ttNuWvP6IcgVvwJ9cg7CkQbABPC/NNpp7LVGYupuoa+SPr+gF7YZulbxizBh x1EMVY9QLuUPU9VXz8q3TnGv2SEl2cqnnmWCzkrysrN7qZ6uRJd4ZiSPKbHOpAhQgf f1gz4LOGRL119AvWpmEo6fWIBHeDzErhuLmoEf6c=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id B4XeCMxNa87H; Fri, 30 Apr 2021 00:30:23 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id A5423160083; Fri, 30 Apr 2021 00:30:21 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Fri, 30 Apr 2021 10:30:18 +1000
Cc: Sara Dickinson <>, Tim Wicinski <>,, The IESG <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Duke <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Apr 2021 00:30:30 -0000

> On 30 Apr 2021, at 09:28, Martin Duke <> 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

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: