[DNSOP] comments on dnssec-validator-06

"Rose, Scott" <scott.rose@nist.gov> Wed, 21 February 2018 17:22 UTC

From: "Rose, Scott" <scott.rose@nist.gov>
To: daniel.migault@ericsson.com, Dan York <york@isoc.org>, Edward Lewis <edward.lewis@icann.org>
CC: dnsop@ietf.org
Date: Wed, 21 Feb 2018 09:22:13 -0800
Message-ID: <43B92B9F-3919-46E3-9714-F40510947EEE@nist.gov>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_38520E33-3991-4713-A0C7-1D52F34B2B40_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sfgp3WmkxRZcfaZx4shh7Y7Gvu0>
Subject: [DNSOP] comments on dnssec-validator-06
Precedence: list

Is this draft still alive?  It’s active, but don’t see much 
discussion, so I’d thought I would present some comments.  Some may be 
my misunderstanding of the intent, in which case I would argue the text 
isn’t clear enough for dummies like me :)

Section 5, last sentence
"...the mechanisms may have to update the time over an unsecure DNSSEC 
resolution."  change to "...an insecure DNS resolution."?

REQ2:
"SHOULD NOT start validating" - meaning not using that particular TA 
that did not verified, or not do any validation?  Could be ambiguous as 
it is stated now.

Sec 6.2
"Such inspection aims at detecting an non successful..."  change to 
"...detecting a non-successful..."

REQ8:
"A DNSSEC validator MUST be able to flush the cached RRsets that rely on 
a given Trust Anchor." Inserted "given" just to clarify.

Section 7.1
"teh" is used a lot instead of "the".  Plus "validte"/validate.  The 
whole doc could use a copy edit pass.


REQ9:
The requirement says that the "ZSK/KSK database MUST NOT be resilient to 
DNSSEC validator reboot", but the paragraph that follows
says that the "ZSK/KSK Data Store is expected to be resilient to 
reboot."  Are these parts discussing the same thing?  If so, that sounds 
contradictory.

REQ17:
"A DNSSEC validator MUST be able to flush the cached RRsets associated 
with a given KSK/ZSK."  Inserted "given", just to clarify.

Section 8, last paragraph
If the child zone is considered bogus, shouldn't the child zone KSK 
become a negative trust anchor instead of a trust anchor KSK?
The validator has no way to insure that he child KSK is valid (unless 
seen before). If it was previously validated and put in the
KSK/ZSK database I can see adding it to the Trust Anchor store (maybe), 
but otherwise, it should become a negative trust anchor.

REQ18:
Wouldn't just any query accomplish that?  RFC6975 says that servers must 
not strip RRSIGs from responses based on what the client
advertises.  It is only used as a signaling mechanism for when to 
complete an algorithm rollover.


Let me know if I need to clarify any of the above.  I could also do a 
more intense copy edit if you would like, but I’m not an expert on 
that.

Scott


===================================
Scott Rose
NIST ITL
scott.rose@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
===================================

[DNSOP] comments on dnssec-validator-06 Rose, Scott