IETF Logo Mail Archive

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

Sara Dickinson <sara@sinodun.com> Thu, 29 April 2021 12:51 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 57A0C3A3D99; Thu, 29 Apr 2021 05:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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 y22ltKlV9k7D; Thu, 29 Apr 2021 05:51:41 -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 09A583A3D7F; Thu, 29 Apr 2021 05:51:40 -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:From:Subject; bh=ZQ3pGX7g333nitUzxuuRa2RT8Y0Hj+SdYTWo7F2PGw8=; b=VKyTKWrtwPU4cHSR9N2g5RS5ez hfN0MA7Y+T2IQ7kQ0NG6MltTB9kZXzWDQKSJmZRVUiQceT8MA0Bf4GhQW7D0LcAFMOhVEgmxkJnEM QJDBfZmfiSTqGsjxBbQDquuP3AISi42GgMb+VF5lXppEwRRqJmgUTmhPlLUJ9d97G4TZIQzf1HwEn TkK8GxK3PhViK6JeTD3DiFDAlVrRlyIQNw7kz2np6BvhE8qgNNrmhLtSQjLnSJi8NQ69iCc/+iZFX QRUV1ZDLtMv5/Dl+bGgledyhT/yq8wMwf0CX1cKb3t0lfuDCQ8occhTp5gGt7ihVzrO9HFCb1An0G lj3NLruw==;
Received: from [62.232.251.194] (port=30324 helo=[172.27.240.7]) 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 1lc68o-0007O3-KO; Thu, 29 Apr 2021 13:51:38 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <7d8fa1d2-ef1a-4ed3-b660-955248a4ec63@www.fastmail.com>
Date: Thu, 29 Apr 2021 13:51:29 +0100
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>, tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6EA2360-CC95-4805-AC90-61C8B294B9BB@sinodun.com>
References: <161921129877.20343.10624609154750488813@ietfa.amsl.com> <034F6C49-0195-4FAF-9EF2-1E39E809F902@sinodun.com> <7d8fa1d2-ef1a-4ed3-b660-955248a4ec63@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3445.104.20)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/uM6ilpzTDJZKZW5JiUjK6Fbcaqk>
Subject: Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with 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, 29 Apr 2021 12:51:46 -0000


> On 29 Apr 2021, at 01:09, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote:
>> 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. 
> 
> No new protocol should use TLS without ALPN.  It only opens space for cross-protocol attacks.  Did the working group consider this possibility in their discussions?

What the working group asked for following the ALPN discussion was that the document contain a description of the options an authoritative nameserver that supports XoT can use to manage TLS connections and the queries received on those connections  - that is provided in Appendix A: https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A

As more context, the document also covers various existing mechanisms that can be used to manage zone transfers (including IP ACLs and TSIG) and how they combine with Strict and Mutual TLS authentication. The document specifies that the server MUST use either an IP ACL or mTLS to authenticate the XoT client. 

Regards

Sara.

v2.23.0 | Report a Bug | By Email