From nobody Thu May 6 07:08:52 2021 Return-Path: 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 1B99A3A2387; Thu, 6 May 2021 07:08:47 -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 i4_hw6V2VqI7; Thu, 6 May 2021 07:08: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 9D76E3A238A; Thu, 6 May 2021 07:08: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=2tLRI8QE5H8slXCkM04h/PYIEpIAuu8H2loq8D48rZw=; b=Kz273Oa+OMqcj2FuC4BRjqpMPA Iw3JG0LwqLA3oMhNwVLjELkzDMyUpYdtaShgJ4WsbvXRfJmqEmw+dFYp0lsiz9+tg489fQ1o46mrI DGkVwUNsL3mzPb1Hn8WJfiejAdHJLyCJt14fJxOr7oCyXDQO5NYuV5+S/IPFmsy3+T/LAd2z5jtY8 9emU1LRXStKPFNwmr38VH7c+BJfg+LILchGgDMD1FoNmKyemEb1ndAtry5ScLQYOQrYbiTG9hrHk1 XhJdlZheZztDQuz0J4/iliVYszHYqFo8ZzLbmUR0A7ganLJEMi/HkblDpEC7GfzWe9aqn1dyC9nKE AIUXc6nA==; Received: from [62.232.251.194] (port=7852 helo=[172.27.240.2]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1leeg8-0006bE-3t; Thu, 06 May 2021 15:08:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) From: Sara Dickinson In-Reply-To: <20210506021211.GF79563@kduck.mit.edu> Date: Thu, 6 May 2021 15:08:34 +0100 Cc: Tim Wicinski , DNS Privacy Working Group , The IESG , draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <290A160B-8B4B-49BB-921A-AD3DC1804063@sinodun.com> References: <162018984115.28455.12313533259326172808@ietfa.amsl.com> <20210506021211.GF79563@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.20) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [dns-privacy] Benjamin Kaduk'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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 14:08:47 -0000 > On 6 May 2021, at 03:12, Benjamin Kaduk wrote: >=20 > Hi Sara, >=20 > On Wed, May 05, 2021 at 04:09:55PM +0100, Sara Dickinson wrote: Hi Ben,=20 Thanks for the detailed response. >=20 >>>=20 >>> But, for concreteness: the text in Sections 8.4, 10.4, and 11 treat >>> cryptographic mTLS, TSIG, and SIG(0) authentication as providing an >>> equivalent level of protection to the (non-cryptographic) IP ACL. = My >>> understanding is that IETF consensus is to prefer cryptographic >>> mechanisms for authentication and authorization, when available. >>=20 >> That wasn=E2=80=99t the intention at all, and we are happy to add = text to clarify that.=20 >>=20 >> To address this I would propose the following updates: >>=20 >>=20 >> Section 8.4: >>=20 >> OLD: >> " o the server MUST validate the client is authorized to request or >> proxy a zone transfer by using one or both of the following: >>=20 >> * an IP based ACL (which can be either per-message or per- >> connection) >>=20 >> * Mutual TLS (mTLS) >>=20 >> NEW >>=20 >> " o the server MUST validate the client is authorized to request or >> proxy a zone transfer by using one or both of the following: >>=20 >> * Mutual TLS (mTLS) >>=20 >> * an IP based ACL (which can be either per-message or per- >> connection) >>=20 >> If only one method is selected then mTLS is preferred because it = provides strong cryptographic protection." >>=20 >=20 > I think in some sense even being listed as sibling bullet points can = imply > "equivalent" for some readers, and accordingly this is not what I see = as an > ideal change. But the new text does acknowledge the qualitative = difference > and is something I would be able to accept, even if it is not my most > preferred outcome. One option here is to update the second bullet point to be a combination = of IP ACL + TSIG to provide additional protection. As mentioned, this is = what is done in practice today by anyone who wants to control TCP zone = transfers. TSIG was earlier discounted as a standalone option (see my = comment below) and with hindsight I=E2=80=99m surprised we didn=E2=80=99t = propose the combination instead.=20 >>>=20 >>> Relatedly, the text in Section 8.4 says that TSIG/SIG(0) are "not >>> sufficient to authenticate the client or server", which is = technically >>> true, but also seems misleading. In XFR scenarios it's not clear = that >>> specific identification (authentication) of the counterparty is >>> necessary for secure operation, if authorization to receive/send the >>> zone can be established without specific identification. My >>> undersatnding is that, when combined with a strict TLS profile for >>> server authentication and appropriate trust policy on TLS clients, = TSIG >>> and SIG(0) both serve to provide proof of authorization for the = exchange >>> even though they only provide authentication in the form of group >>> membership (the relevant key material is typically available to = multiple >>> machines). As such, don't they provide strong enough cryptographic >>> protection (and end-to-end, no less!) to be a superior authorization >>> mechanism than an IP ACL? (Any resulting text changes may bleed = into >>> Sections 11 and 12 in addition to 8.4, per my COMMENT.) >>=20 >> So I _think_ your question here is why isn=E2=80=99t TSIG also = considered a valid option in combination with Strict TLS? >=20 > Yes, that's a fair summary. >=20 >> The reason is that TSIG signed requests can be forwarded by a third >> party. The signature is ONLY over the DNS message payload, so it = doesn=E2=80=99t >> cover the identity of the originator. That means that if only a TSIG = is >=20 > Yes. Part of my point is that the specific identity of the originator = is > not always needed, if authorization to receive a transfer can be = determined > without knowing the actual identity. >=20 >> required, the server cannot be sure that the client originating the = TLS >> connection is not an on-path attacker forwarding requests, and = therefore >> inspecting the zone transfer responses. (The real value of TSIG is = that >=20 > Yes. But in order to get into such an on-path position the attacker = would > have to compromise the strict TLS required by the original client. An > attacker that can do that could also inject themself as on-path for a = pure > mutual TLS solution. In this sense we could consider that, when an > (authorized) client sends an XFR+TSIG to a proxy on a TLS connection = where > strict server certificate validation has succeeded, the client is > delegating its authorization to receive the XFR to the proxy, and thus = that > the proxy is also authorized to receive the transfer. One concern is that an attack or misconfiguration that resulted in the = client sending the XFR request in clear text would allow the attacker to = obtain the signed message for replay. Since this is a migration from a = clear text protocol to a TLS based protocol that doesn=E2=80=99t seem = impossible. Whereas compromising mTLS directly is somewhat more = challenging?=20 >=20 > TSIG of course does allow more than one proxy in a chaing, which does > introduce questions of transitive trust, but I believe that an = attacker > that is capable of compromising strict TLS + TSIG is also capable of > compromising mutual TLS. And also, because such an clear text message could be sent anywhere = along that chain it seemed to exacerbate the problem... Thanks Sara.=20