[secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 14 September 2015 00:08 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DC1A91B41E8; Sun, 13 Sep 2015 17:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id f1_9acn4_FaE; Sun, 13 Sep 2015 17:08:04 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2D81B42A5; Sun, 13 Sep 2015 17:08:04 -0700 (PDT)
Received: by obbbh8 with SMTP id bh8so96725049obb.0; Sun, 13 Sep 2015 17:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nDaeZG1f4qEKH0W8VuBhL1nMA5zjDUiPgcI1KHMdFHQ=; b=gTXJJANsaktWFpkMcY6V+nkRdZcAShB3Yi4wjI4amS+gukAG79hNmMhXs+m7Zay3Gn TuBURr6W2prG8LWUT8vNDpDtaDgPYFy+CQHbKDuukjuaECKe9jUa+fsIp28CaYHpVw/K XCU6wtEM7hrDIQf2ddJ26ZN5k34VlDA5A3hPz7mN8siuVNgIDEKDlNNkFlkgKDPwnJU0 7bAIcSNKxaYR8JJFGjWdKoPY6cMnPw0VsCS32yQ3DYi2Wc+BoavvgMGqaz4xy7atSWnE rXPdP8Yeb77EMq+Bro8P4ArA5gdiChOCtilkZoJ1r3qhcBp+gPFX9L+wdqkWwLHPdYZ/ AoFg==
MIME-Version: 1.0
X-Received: by with SMTP id i9mr8612330obh.59.1442189283423; Sun, 13 Sep 2015 17:08:03 -0700 (PDT)
Received: by with HTTP; Sun, 13 Sep 2015 17:08:03 -0700 (PDT)
Date: Sun, 13 Sep 2015 20:08:03 -0400
Message-ID: <CANTg3aAPYVTHzLLDNBKCpikCFREqHSpsAe_vHm8Z7LVTjSKyCg@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c2989eeffbcb051fa9db6a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/SxMkg6D0VyHyQSChcDxMqJ1Lf6U>
Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org
Subject: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Sep 2015 00:08:06 -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.

This draft is essentially ready for publication (with minor comments below).

This is an Informational document that specifies how the operator of a
recursive resolver could run a copy of the root zone on a loopback
interface. The purpose of this mechanism are two-fold: (1) to speed
response time in the case of a negative response from the root zone; (2) to
hide queries to the root zone from malicious observers.

The security story for this mechanism is essentially:
A) Since this mechanism must be run on a loopback interface, there is
no possibility that the mechanism will negatively impact other entities.
(I.e., it would be bad if a recursive resolver started giving authoritative
answers for the root zone to anyone other than itself.)
B) DNSSEC is used to ensure that the answers provided by this mechanism are

The security considerations section for this document is somewhat terse and
I believe the document could be improved by expanding that section. In
particular, I believe that point (A) above should be stated explicitly in
the security considerations section. (That is, it is stated elsewhere in
the document that using a loopback mechanism is essential. However, I think
that repeating that in the security considerations section would be helpful
-- I think that point is an important part of the story for why this
mechanism doesn't break things.)

Additionally, in the security considerations section, the authors are
somewhat brief in describing the need for DNSSEC. I think that is fine, but
given the brevity, I think it would be helpful to have a citation to
another document that describes why DNSSEC is needed. (Is RFC 4033 the best
reference regarding what DNSSEC protects against? Or is there a better
document now?)

- Matt Lepinski