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

Sara Dickinson <sara@sinodun.com> Thu, 06 May 2021 10:32 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E695F3A1C1C; Thu, 6 May 2021 03:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts9e0Hxa-4L3; Thu, 6 May 2021 03:32:24 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8593A1C1A; Thu, 6 May 2021 03:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=mNt00xM+Q0EnTMmHP6FWcDVtjXswUZ3/T7H/XpG2RfU=; b=P71kELhmhUfHtl4n7Whk3wJrEJ Cngy4FZQ4oQE75qIqvlv6y94+9y2auUHbQfzy8NrvC3MiqkpmAztqSQ/ZzwVYiB0dO+7zG1nkbwAI +5rCB75A0/l2xjNCj7qdhQPZYQLxcLznnmM30UfWXzzXnhifOYqFSUZOUuc4hVxGS8cOPu0Xv9y5e w+tAkLTNg3rVIU/PqdSvsCoInU6H34Y0UPP/ENLC5gq0iQ0ZME94U2NNMDpcNfWmN2P4fZuLYXvbx sVhzd0rrE6nM/Rx+hM3mbrz2CU5VqeFuAq4YTZpdwt5MOvAsbk9LDFeOvYe9Z7/Xlduc48ds559vd 9T2E9rew==;
Received: from [62.232.251.194] (port=24397 helo=[172.27.240.5]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1lebIp-0006so-QE; Thu, 06 May 2021 11:32:20 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <0670E630-1616-41C6-A3F2-3D17DEDB714B@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_76C056DC-9365-4782-87F1-8EBD286FFEED"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
Date: Thu, 6 May 2021 11:32:17 +0100
In-Reply-To: <CAM4esxQNyY+pZb-Dw7grKneULGfwjt5pV5GLjBsH9hf_Jp=yAQ@mail.gmail.com>
Cc: Allison Mankin <amankin@salesforce.com>, The IESG <iesg@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dns-privacy@ietf.org, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org
To: Martin Duke <martin.h.duke@gmail.com>
References: <162006706040.3639.6179900042922096790@ietfa.amsl.com> <CALUxDspOEaSGnUdhh2ASFp6wOc66pdEy+kdRQudgw0EG-C3K9Q@mail.gmail.com> <CAM4esxQNyY+pZb-Dw7grKneULGfwjt5pV5GLjBsH9hf_Jp=yAQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.20)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/yuDImwmP9ywC0XYBSst-mXkF1Lc>
Subject: Re: [dns-privacy] Martin Duke's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 10:32:30 -0000

Hi Martin, 

Just to follow up, the following exchange was had with Ben, who also raised a DISCUSS on the topic of ALPN:

> As Allison already stated in reply to Martin, the authors agree that the `dot` ALPN should be used here, in light of the recent discussions. 

> 

> In terms of updating the text, I believe what is required is to add a new section at the start of section 8:

> 

> "8.1 Connection establishment

> 

> During connection establishment the ALPN token “dot” [ref] MUST be selected in the crypto handshake.”


(I'd s/crypto/TLS/, myself, but that's hardly critical.)

> I believe the later text relating to XoT vs ADoT in section 8.6 is still fully applicable, unless you see something you believe also needs updating? 


I also think that part looks fine.

> I will also update the first paragraph of Appendix A to reflect that the main reason for not using a separate ALPN (as originally proposed) is actually because XoT is DNS and so should share the `dot` ALPN. 


Good catch; thanks!


I hope this addresses your DISCUSS too?

Regards

Sara. 




> On 3 May 2021, at 20:35, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Excellent,
> 
> Thanks for clarifying.
> 
> On Mon, May 3, 2021 at 12:32 PM Allison Mankin <amankin@salesforce.com <mailto:amankin@salesforce.com>> wrote:
> Hi, Martin,
> 
> Sara is out of the office for a day or two, so I will jump in.  We do not object to using an ALPN code for DoT, and indeed, the message that ALPN should not distinguish between DoT and XoT drowned out the more important message that ALPN for DoT had to be there.  A miss by the earlier reviewers.
> 
> Allison
> 
> 
> Allison Mankin, Principal Architect, DNS-AEO Cloud Leader | Salesforce
> 
> 
> 
> 
> On Mon, May 3, 2021 at 2:37 PM Martin Duke via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-dprive-xfr-over-tls-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/>
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> In further discussions it became clear that the authors do not intend for XoT
> traffic to use an ALPN code at all. I'm afraid this may be a misunderstanding
> of previous guidance from TLS that XoT did not need its own ALPN code, but
> could simply use the DoT ALPN since the messages are distinguishable on the
> wire.
> 
> To not use an ALPN at all violates best TLS practice. The reasoning given in
> Appendix A, that this creates difficulty for proxies, doesn't make sense to me.
> We can talk about it in the telechat.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - 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.
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org <mailto:dns-privacy@ietf.org>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>