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

Martin Duke <> Thu, 29 April 2021 23:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2426A3A17C8; Thu, 29 Apr 2021 16:29:09 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HY9OGgAbvecn; Thu, 29 Apr 2021 16:29:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF7E93A17CD; Thu, 29 Apr 2021 16:29:06 -0700 (PDT)
Received: by with SMTP id y6so1357779ilq.10; Thu, 29 Apr 2021 16:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3kBR+z7c7FTzKiGWAsQhC6jOBop+xqdFO5xbLqiKOb4=; b=RBg0uiIWpvSSUOUEsj78T84hMcYp85wGvxtWjbWY5dzWlHj9ZfQbfOlBOxP8XrRu1x FuSwwABB5TPNAc4jSW02UslwsykOTzf7RsUrJFP1GOO4Jbp4aPMTy08zGhEkuLH2ILqk w241XpYx6gobbIoI45f2wDcQFry0XNiOqBZbCDLK6Aif0llqWJVvGSDllTc/M4UwVsI1 qSbpH3gZIup12AfHruKdAgRET1y4dsOmBd/c9/elXBZkJx9d2iOYK41btcRSzXC6cwwA nfyZLIU61Y+5/HeMJhZzSPibSJ0J/j5nLO8wdMd17ErRd2I3YysJ2ieC5hkfHjbTU5ME fKnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3kBR+z7c7FTzKiGWAsQhC6jOBop+xqdFO5xbLqiKOb4=; b=leNM70+PupQR5k3rSaHVSBv/TY4WHsq3CSTmzMOfWa5rcmoA3QujnbQaqoLjMvgQIX QNf/sJhynW600+o4MJBCVQDDekfz7U44eqRLN4umTqbvKPvEGYJdyi2qemDA/JNg2rsK qXMuTnPZRXqRITTEwcp/JiO4LABVSCOJm0trAgeBnGJH0ElA9yUhmzJKhjf+DZTpQn7L 5PeD8laWAXgBxVGiLDwdQFyeSwPV0/K44ly4lTZBfL/x1r5rnpzxFBPYSeHmq3lHkb0u mLMh8mpzxIyS5H9MnhYfbsvBH1ZPqBR+26t6ZM7d6IDv/LmvwRQNlhKeghWsAaRlGyc2 BeoA==
X-Gm-Message-State: AOAM532GZX8TQ6mBSW1YyDjJaS6NrnCgwmQsCGCLS1lSsjaAteAuuSfV saaouKeaZG49UBjRjcom87SHPBTVv/mJTV4KREs=
X-Google-Smtp-Source: ABdhPJz4/5hvs5b9YePHmaeOnp8xeMtwJl/30jta8jNbUFuzcfgZAzmFF/MHWTRIaQ+rdIhdk+8ugjm2Vf60w66O3eg=
X-Received: by 2002:a05:6e02:4c4:: with SMTP id f4mr1778749ils.272.1619738945557; Thu, 29 Apr 2021 16:29:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Thu, 29 Apr 2021 16:28:56 -0700
Message-ID: <>
To: Sara Dickinson <>
Cc: The IESG <>,,,,
Content-Type: multipart/alternative; boundary="0000000000007a996905c124dcd6"
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: Thu, 29 Apr 2021 23:29:09 -0000

Hi Sara,

> > - Please explicitly state that, IIUC, these XoT connections use the DoT
> 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
> > 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?