From nobody Wed May 5 08:10:16 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 2D2583A113C; Wed, 5 May 2021 08:10:15 -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 vx5fNmENd8Fq; Wed, 5 May 2021 08:10:09 -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 6AD383A1138; Wed, 5 May 2021 08:10:09 -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=obHLnJ4WDzE8AsE2r2Hy3CBjXCJ9sY5AhMqUSTE8QzU=; b=oKxjqdQ2Jmal9n9j6pnTGZ5Nls NmZ54pVM4UZhvZQ/D1UgDHghoLZ4DN6PDaVWW/T9USD2p/ylx0b9ZmW7JA10ce9g1/JnxuoFqw5VZ stpfNYitSP9JnwfD/pa9s7uFUMGS3W8u6kkBDh95g7pgtLe72xUDYogUh93UTblfzBYFcbFx8VGVa kH4tp4etP3lVMfe21P/qTk9ZniuGGt7pYHQhKfiucbArnZYz4ULGzwhTXuLccVwWntFXfQia91vG7 jIwFgLbbP2elLRnvX5Ef8VqYBZcfhH6IE9Pbl/RwZ2Np+9RyH8EbApgJDY5wPcRfEAdrtC5U4Mx9m X2J+R+Jw==; Received: from [62.232.251.194] (port=27174 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 1leJA6-0005Qj-3N; Wed, 05 May 2021 16:10:06 +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: <162018984115.28455.12313533259326172808@ietfa.amsl.com> Date: Wed, 5 May 2021 16:09:55 +0100 Cc: The IESG , draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, DNS Privacy Working Group , tjw.ietf@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <162018984115.28455.12313533259326172808@ietfa.amsl.com> 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: Wed, 05 May 2021 15:10:15 -0000 > On 5 May 2021, at 05:44, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dprive-xfr-over-tls-11: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 Hi Ben,=20 Thanks for the review. I=E2=80=99m addressing just the DISCUSS points in = this mail and will follow up separately on the COMMENTS: >=20 > My understanding is that this point is essentially overtaken by = events, > as a similar concern was raised already by Martin D, John, and Roman, > and there is a commitment to update the text already made. I'm = putting > it in at the Discuss level to make sure that I follow-up on the = revised > text when it appears. 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.=20 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 =E2=80=9Cdot=E2=80=9D = [ref] MUST be selected in the crypto handshake.=E2=80=9D 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?=20 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.=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. That wasn=E2=80=99t the intention at all, and we are happy to add text = to clarify that.=20 To address this I would propose the following updates: Section 8.4: 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: * an IP based ACL (which can be either per-message or per- connection) * Mutual TLS (mTLS) NEW " o the server MUST validate the client is authorized to request or proxy a zone transfer by using one or both of the following: * Mutual TLS (mTLS) * an IP based ACL (which can be either per-message or per- connection) If only one method is selected then mTLS is preferred because it = provides strong cryptographic protection." Section 10.4 (similar to text already proposed to Martin Duke). Add at = the end of the second paragraph: =E2=80=9CmTLS provides a stronger authentication of the client than an = IP ACL because it is based directly on a cryptographically verified = identity.=E2=80=9D Section 11: OLD: =E2=80=9CThe following table summarizes the properties of a selection of = the mechanisms discussed in Section 10." NEW: "The following table summarizes the high level properties of a selection = of the mechanisms discussed in Section 10 (it does not, however, imply = that methods that share the same basic property provide equivalent = protection.) OLD: =E2=80=9C * Using just Mutual TLS can be considered a standalone = solution since both end points are cryptographically authenticated. * Using Strict TLS and an IP based ACL on the primary also provides = authentication of both end points=E2=80=9D NEW: =E2=80=9C * Using Mutual TLS is a standalone solution since both end = points are cryptographically authenticated. This is the preferred mode = because it provides the strongest protection. * Using Strict TLS and an IP based ACL on the primary also provides = authentication of both end points, although here only the server is = authenticated cryptographically.=E2=80=9D >=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.) So I _think_ your question here is why isn=E2=80=99t TSIG also = considered a valid option in combination with Strict TLS? 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 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 the client can be sure the response hasn=E2=80=99= t been tampered with and so it has a valid XFR response before applying = the update, but in practice it is also widely used today in combination = with IP ACLs to limit the sending of XFR responses).=20 I think we could improve the text to clarify this. How about: Section 8.4 OLD: =E2=80=9CThe server MAY also require a valid TSIG/SIG(0) signature, but = this alone is not sufficient to authenticate the client or server.=E2=80=9D NEW: =E2=80=9CThe server MAY also require a valid TSIG/SIG(0) signature, but = this alone is not sufficient to authenticate that the TLS client is = authorised to receive a XoT transfer (e.g., is not an on-path attacker = forwarding TSIG/SIG(0) signed DNS message payload.)=E2=80=9D And then in section 10 I=E2=80=99ll make clear that only the DNS message = payload is signed with TSIG (it currently says =E2=80=98message/DNS = message=E2=80=99, which is unclear).=20 Best regards Sara.=20