Re: Last Call: RFC7344 Automating DNSSEC Delegation Trust Maintenance to standards track
Benjamin Kaduk <kaduk@mit.edu> Tue, 15 November 2016 05:46 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3BA1295F2 for <ietf@ietfa.amsl.com>; Mon, 14 Nov 2016 21:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Level:
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eq3t1T0RCjrt for <ietf@ietfa.amsl.com>; Mon, 14 Nov 2016 21:46:17 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 59A911295C3 for <ietf@ietf.org>; Mon, 14 Nov 2016 21:46:17 -0800 (PST)
X-AuditID: 12074423-d4fff70000003bb4-38-582aa12756e0
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id BF.71.15284.721AA285; Tue, 15 Nov 2016 00:46:16 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uAF5kFBb014298 for <ietf@ietf.org>; Tue, 15 Nov 2016 00:46:15 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAF5kCXr003670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Tue, 15 Nov 2016 00:46:14 -0500
Date: Mon, 14 Nov 2016 23:46:12 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: ietf@ietf.org
Subject: Re: Last Call: RFC7344 Automating DNSSEC Delegation Trust Maintenance to standards track
Message-ID: <20161115054611.GN86797@kduck.kaduk.org>
References: <147908623055.5563.514732510355874303.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <147908623055.5563.514732510355874303.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUixCmqrKuxUCvCYM1yRotnG+ezODB6LFny kymAMYrLJiU1J7MstUjfLoErY8/sN4wF3wUq+jp/MjcwfuPtYuTkkBAwkbjZsZili5GLQ0ig jUli+pqfUM5RRon2GwuYIZyXTBJvZixmAmlhEVCVON/6FcxmE1CRaOi+DFTEwSEiIChx8LEl SFhYIFniztK7jCA2L9CGw9tuM4PYQgLeEh+vNLFAxAUlTs58AmYzC2hJ3Pj3kglkDLOAtMTy fxwgJqeAj8TeH2ATRQWUJRpmPGCewMg/C0nzLCTNsxCaFzAyr2KUTcmt0s1NzMwpTk3WLU5O zMtLLdI108vNLNFLTSndxAgKO3YX5R2ML/u8DzEKcDAq8fDuOKoZIcSaWFZcmXuIUZKDSUmU 99J8rQghvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwXuoByvCmJlVWpRfkwKWkOFiVx3v9uX8OF BNITS1KzU1MLUotgsjIcHEoSvCYLgBoFi1LTUyvSMnNKENJMHJwgw3mAhv8CWcxbXJCYW5yZ DpE/xagoJc77egZQQgAkkVGaB9cLSgsS2ftrXjGKA70izNsAsoIHmFLgul8BDWYCGrzLXANk cEkiQkqqgVHe/8vyGanVR2pFOd0Tb7qfETD8+81/Qlv+lb/fs88u6I8xbPNy/nHEMvzPfGPV Kr5VgRefHZxU0Hs7JeNlx6eXF6eybWTaWR1y1L/P5c2ch0lhcad2MB7XKaj6sanWJ17jmJHd hSMTg7U+Lq8Mtetl37JPh9VUiU1z99T251kp5m94X+5fyqnEUpyRaKjFXFScCABVyMmO5gIA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/QVuF06HLOdyQlpa5gaK6q-gslqw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 05:46:20 -0000
As part of my secdir review of draft-ietf-dnsop-maintain-ds-03 (https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html), I noticed that it indicated that the status of RFC 7344 should be changed to Proposed Standard, and reviewed RFC 7344 at the same time. I repeat those comments here to have them entered into the appropriate archive; I do not think that they merit blocking the status change. -Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Section 3 (of RFC 7344) specifies that the absence of a CDS/CDNSKEY record in the child means that no changes are to be made to the DS records in the parent. An attacker that is able to prevent the parent zone's resolvers from seeing the CDS/CDNSKEY records would thus be able to prevent the DS update, a denial of service. One would hope that the DNSSEC-enabled parent zone would use a validating resolver when it queries the child zone, but it is probably worth mentioning explicitly, and the behavior in the error case when the query fails. It would have been nice if Section 4 had given a fuller description of what it means for the [CDS and CDNSKEY] RRsets to "match in content" when it restricts what the child can publish. Likewise, Section 4.1 could have given more detail as to whether only the parent SHOULD log the error, or if a child might be doing that validation and logging as well. In Section 6.1, where the delegation UI is being used to trigger CDS/CDNSKEY processing and key confirmation, it might be worth mentioning that that UI should be over a secure channel. (It should be anyway, but...) The security considerations text about "this mechanism SHOULD NOT be used to bypass intermediaries that might cache information" feels a bit like "hope and pray that nothing goes wrong", since it may not always be clear to all parties exactly what intermediates might be involved for any given child/parent. More concrete guidance about which parties must do what checking before enabling CDS/CDNSKEY service for which users could be useful. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
- Re: Last Call: RFC7344 Automating DNSSEC Delegati… Benjamin Kaduk
- Re: Last Call: RFC7344 Automating DNSSEC Delegati… Paul Wouters