[secdir] secdir review of draft-ietf-dnsop-edns-key-tag-03

"Scott G. Kelly" <scott@hyperthought.com> Mon, 09 January 2017 19:27 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24B129DA5 for <secdir@ietfa.amsl.com>; Mon, 9 Jan 2017 11:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.056
X-Spam-Level:
X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156] 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 K9uNQbJusEeO for <secdir@ietfa.amsl.com>; Mon, 9 Jan 2017 11:27:21 -0800 (PST)
Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 4453B129449 for <secdir@ietf.org>; Mon, 9 Jan 2017 11:27:21 -0800 (PST)
Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 55DA05A8D; Mon, 9 Jan 2017 14:27:18 -0500 (EST)
Received: from app53.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3A0BA5ACA; Mon, 9 Jan 2017 14:27:18 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app53.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 09 Jan 2017 14:27:18 -0500
Received: from hyperthought.com (localhost [127.0.0.1]) by app53.wa-webapps.iad3a (Postfix) with ESMTP id 2957540123; Mon, 9 Jan 2017 14:27:18 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 9 Jan 2017 11:27:18 -0800 (PST)
Date: Mon, 9 Jan 2017 11:27:18 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-dnsop-edns-key-tag.all@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
X-Auth-ID: scott@hyperthought.com
Message-ID: <1483990038.1669640@apps.rackspace.com>
X-Mailer: webmail/12.7.1-RC1
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SxO4kmS6GFId-yfXIzhzODpahCc>
Subject: [secdir] secdir review of draft-ietf-dnsop-edns-key-tag-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jan 2017 19:27:22 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: this draft is ready.

From the introduction, 

   This draft sets out to specify a way for validating resolvers to tell
   a server in a DNS query which DNSSEC key(s) they would use to
   validate responses from that zone.  This is done in two ways: using
   an EDNS option for use in the OPT meta-RR [RFC6891] that contains the
   key tags (described in Section 4), and by periodically sending
   special "key tag queries" to a server authoritative for the zone
   (described in Section 5).

That pretty well sums it up. The security and privacy considerations sections cover all relevant issues. I see no problems with this document.

Minor editorial comment: section 5.3 ends with this bracketed comment:

 [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

I assume this will be resolved prior to publication?

--Scott