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

"Paul Hoffman" <> Mon, 14 September 2015 15:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8732C1B54BB; Mon, 14 Sep 2015 08:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.552
X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3Fq8h_PSU-G; Mon, 14 Sep 2015 08:17:59 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B59541B4358; Mon, 14 Sep 2015 08:17:59 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t8EFHv8w079126 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 08:17:57 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Paul Hoffman <>
To: Matthew Lepinski <>
Date: Mon, 14 Sep 2015 08:17:56 -0700
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <>
Cc:, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Sep 2015 15:18:00 -0000

Thanks! We have made these changes in the pre-draft of -04. If the ADs 
want us to publish this before the IESG review, we can; otherwise, we'll 
wait until after the IESG review to release them.

--Paul Hoffman

       <t>A system that does not follow the DNSSEC-related requirements 
       in <xref target="reqs"/> can be fooled into giving bad responses 
in the
       same way as any recursive resolver that does not do DNSSEC 
validation on
       responses from a remote root server. Anyone deploying the method
       described in this document should be familiar with the 
operational benefits
       and costs of deploying DNSSEC <xref target="RFC4033"/>.</t>

       <t>As stated in <xref target="intro"/>, this design explicitly 
only allows
       the new root zone server to be run on a loopback address, in 
order to
       prevent the server from serving authoritative answers to any 
system other
       than the recursive resolver. This has the security property of 
       damage to any other system that might try to rely on the copy of 
the root
       in case that copy becomes altered.</t>