Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 22 January 2016 17:28 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0460E1B2AA9 for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2016 09:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.047
X-Spam-Level:
X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] autolearn=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 cFgU_Mgj2_Xe for <dnsop@ietfa.amsl.com>; Fri, 22 Jan 2016 09:28:19 -0800 (PST)
Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0B66F1B2AA8 for <dnsop@ietf.org>; Fri, 22 Jan 2016 09:28:19 -0800 (PST)
Received: from [10.32.60.117] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u0MHSGu1011411 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2016 10:28:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.117]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 22 Jan 2016 09:28:21 -0800
Message-ID: <E764A09B-3E16-4F93-96B4-B8CDDEBE766B@vpnc.org>
In-Reply-To: <CAJE_bqdN-dn8VHmQo-iVOo40Z40=8SeK-3CvFKT7jTr-qJ4LOA@mail.gmail.com>
References: <E19574D8-7460-4910-B65F-5355DFCA7313@vpnc.org> <CAJE_bqfWFGfjmXwEhXNfEsE_crH6e51Y1HrYrCD4AnWHwMVSiQ@mail.gmail.com> <4DC64D5D-CCCD-4A07-A285-C9E16773F56C@vpnc.org> <CAJE_bqdN-dn8VHmQo-iVOo40Z40=8SeK-3CvFKT7jTr-qJ4LOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/q3w_tRuHLd0aHKBShAGpaQbr2oA>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2016 17:28:20 -0000

On 15 Jan 2016, at 10:03, 神明達哉 wrote:

> My incremental different suggestion was to revise it further:
>
>  [...]  This would be when the resolver starts with an empty cache,
>  and when the NS RRSet for the root zone has expired.
>
> Is it clear enough now, or did you mean this last text has an issue
> (like as if it talked about zone expiration)?

This is fine, and it will be in the next version.

>
>>> - Section 3.3
>>>
>>> [...]  At the time this
>>> document is being published, there is little use to performing 
>>> DNSSEC
>>> validation on the priming query because the "root-servers.net" zone
>>> is not signed, and so a man-in-the-middle attack on the priming 
>>> query
>>> can result in malicious data in the responses.
> [...]
>> The first bullet point is not necessary for your argument. Would the
>> following be better than the quoted sentence?
>>
>> At the time this document is being published, there is little use to
>> performing
>> DNSSEC validation on the priming query. This is because being able to
>> validate
>> the NS records is not sufficient for having authenticated addresses 
>> for
>> the root
>> servers: having validated A and AAAA RRsets for each root server is 
>> also
>> needed.
>> Without those validated A and AAA RRsets, a man-in-the-middle attack 
>> on
>> the
>> priming query can result in malicious data in the responses
>
> Looks good to me (I'd say "A and AAAA RRsets for each root server
> *name*" though).

Please see the message I sent yesterday with Warren's challenge about 
this section. It would be good for the WG to come to consensus on the DO 
bit before we do more wordsmithing.

>
>>> - Section 4.1
>>>
>>> answer section) and an Additional section with A and/or AAAA RRSets
>>> for the root name servers pointed at by the NS RRSet.
>>>
>>> Similar to the previous point, it seems to be based on some implicit
>>> assumptions including:
>>> - all root servers are authoritative for the root-servers.net zone
>>> - all these servers populate the additional section from a different
>>> zone they are authoritative for than that for the query name ("."
>>> in this case)
>>> - none of the root server implementations use the
>>> "minimal-responses" (or equivalent) option
>>>
>>> I think these should be clearly stated.
>>
>> Those implicit assumptions are not needed for the current text. RFCs
>> 1034 and 1035 and 2181 do not restrict what can be put in the 
>> Additional
>> section to only being things for which the server is authoritative.
>
> Right, but there's no requirement what to be put in the additional
> section, so this "expected property" relies on a particular
> implementation behavior (rather than something we can expect from any
> "protocol-compliant" implementation).  That's fine to me, but I
> thought it should be clearly stated.

This is a good point: the current text conflates all three things. How 
about:

The priming response is expected to have an RCODE of NOERROR, and to 
have the
AA bit set. Also, it is expected to have an NS RRSet in the Answer 
section (because the
NS RRSet originates from the root zone), and an empty Authority section 
(because the
NS RRSet already appears in the answer section). There may be an 
Additional section with A
and/or AAAA RRSets for the root name servers pointed at by the NS RRSet.

--Paul Hoffman