[dns-privacy] John Scudder's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Tue, 04 May 2021 20:02 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E93AF3A10E4; Tue, 4 May 2021 13:02:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <162015857648.17895.7104332787108510127@ietfa.amsl.com>
Date: Tue, 04 May 2021 13:02:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/cz5ktFS4eqxxd4MiTe0XoGvyfac>
Subject: [dns-privacy] John Scudder'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
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: Tue, 04 May 2021 20:02:57 -0000
John Scudder has entered the following ballot position for draft-ietf-dprive-xfr-over-tls-11: No Objection 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 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the well-written and easy to follow spec. Below are some comments you may want to take into consideration. 1. Abstract XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. Please say a few words about how the spec updates those RFCs, don’t make the reader go digging for it. 2. Section 1 transfers (this draft) is orthogonal to preventing zone enumeration, though they aim to protect the same information. s/this draft/this document/ 3. Sections 6.1, 6.2 3. If the primary serial is higher than the secondaries serial s/secondaries/secondary’s/ 4. Section 6.3 This section attempts to presents a rationale for considering “Attempts to present”. But really, why not just “presents”? 5. Section 6.3 Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers leakage Comma between “servers” and “leakage”. 6. Section 6.3.2 For hidden primaries or secondaries the SOA response leaks only the degree of SOA serial number lag of any downstream secondary. I don’t understand. This either means the sentence would make sense if only I had the right domain knowledge (which is OK then), or it means the sentence doesn’t make sense (which isn’t). 7. Section 7 The following sections include detailed clarifications on the updates to XFR behavior implied in [RFC7766] and how the use of [RFC7828] applies specifically to XFR exchanges. It also discusses how IXFR and AXFR can reuse the same TCP connection. “They also discuss” — agreement in number with “the following sections”. 8. Section 7.4 This specification for XoT updates the guidance in [RFC7766] to provide the same separation of connection purpose (regular queries and zone transfers) for all transports being used on top of TCP. The “for XoT” confuses this sentence, making it sound a bit like the advice is restricted to XoT. I think those two words should be struck, it would be just fine as “this specification updates…” 9. Section 8.1 For improved security all implementations of this specification MUST use only TLS 1.3 [RFC8446] or later. Improved compared to what? I think the first three words could go, then the question wouldn’t come up. 9. Section 8.4 (also 10.4) 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) The former is weaker, surely? I see Martin also raised this in his comments, I agree with what he wrote. It’s odd to see these two authorization methods, with very different security properties, presented as equivalent with no discussion anywhere of their relative (de)merits. 10. Section 8.8.1 (also 8.9.3) The goal of padding AXoT responses would be two fold: “Is”, not “would be” (also 893) 11. Section 10.2 SIG(0) [RFC2931] similarly also provides a mechanism to digitally Similarly, or also — pick one. 12. Section 11 The XoT authentication requirement specified in Section 8.4 addresses the issue of ensuring that the transfers is encrypted between the two “Transfers are” or “transfer is”. 13. Section 11 endpoints directly involved in the current transfers. The following table summarized the properties of a selection of the mechanisms “Summarizes” 14. Appendix A For completeness, it is noted that an earlier version of the specification suggested using a XoT specific ALPN to negotiate TLS Please define APLN on first use 15. A.4 As an aside, whilst [RFC7766] makes a general purpose distinction to clients in the usage of connections (between regular queries and zone Do you mean “general purpose distinction between clients“? The use of “to” doesn’t make sense to me. 16. A.4 Client behavior to REFUSED response is not clearly defined (see below). I do not see anything relevant below.
- [dns-privacy] John Scudder's No Objection on draf… John Scudder via Datatracker
- Re: [dns-privacy] John Scudder's No Objection on … Sara Dickinson
- Re: [dns-privacy] John Scudder's No Objection on … John Scudder