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.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%