On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" 
<dnsop-boun...@ietf.org on behalf of scott.r...@nist.gov> wrote:

>I think this draft is a good idea and should be adopted, but needs some 
>improvements first. 
>

Thanks for the review, the current version has items needing wider discussion.

I'll pick some items to respond to now:

>2. REQ2: What should happen when there are multiple trust anchors, but only 
>one failed to validate? E.g. a validator has both the root and .exampleTLD in 
>its trust store, but missed the root rollover. The .exampleTLD key still 
>validates, but the root doesn't. Should all validation stop? Or set a warning, 
>but continue to validating (succeeding only for .exampleTLD)?

One of my long-standing opinions has been that it is hard to build a secure 
chain, so if one exists, accept it in face of alternative broken chains.  If a 
validator is too "tight" then it would be trivial to do a denial-of-service by 
throwing out DNSKEYs, RRSIGs, etc., that will not lead to validation.

As far as trust anchors, the level of trust (healthiness in some sense) is 
individual.  One anchor candidate might be "false" (unauthorized) while another 
anchor candidate might be "true" (authorized).  Trust is in the 
eye-of-the-operator, if the operator establishes trust in a candidate it is 
best to run with it, again, even if there are untrusted candidates.  (Because, 
if too "tight" it would be trivial to do a denial of service.)

>3. REQ18: I don't think I understand this. Wouldn't the best way to see which 
>algorithm(s) are in use for a given zone would be just to send a query  
>Authoritative zones really may not "know" any algorithm besides SHA-1, as it 
>is likely not doing online signing, but serving whatever a signing utility 
>chose. 

I'd refrain from "know" and use "use."  The signer (not the zone) may or may 
not have a library for a particular DNSSEC security algorithm's needed 
cryptographic algorithm and/or hash.  That's entirely opaque to the other side 
of the DNS protocol (as DNSSEC assumed an air gap in the most strictly secure 
use case).

What is in use for a zone is established two ways.  One is from the DS RRset.  
The other is via published secure entry points bootstrapped to the satisfaction 
of the validator operator's "trust" satisfaction.

I.e., I too think that REQ18 needs further review.  It would make more sense if 
there were on-the-fly signing capabilities (which is not something assumed by 
DNSSEC, although it's not a ludicrous idea, it would be operationally useful).

>4. Should there be a mention as to which algorithms a validator should 
>support? It may not require a direct reference to whichever RFC is current, 
>but simply listing the IANA maintained registry and say "implement all the 
>MUSTs and probably the SHOULDs too". Something like the following:

For turn-key implementations, I don't think so.  For general-purpose 
implementations, the producer of the software would make a choice based on 
their objectives.

Easing the choice for the tool developer would be good, but I question 
mandating compliance with features.  (I'd leave that to the "purchasing 
vehicle", which begs a whole'nuther discussion.  There would be a need to 
educate the consumer, for one.)

>Algorithm Usage in Validators 
>
>DNSSEC signatures can be generated by different digital signatures algorithms. 
>The current list of algorithms defined for use with DNSSEC is published in an 
>IANA maintained registry [insert IANA link here]. Validators have to be able 
>to understand and validate different algorithms that may be in common use with 
>DNSSEC. The DNSSEC digital signature registry table is regularly updated with 
>guidance as to which algorithms are considered MANDATORY and/or RECOMMENDED. 
>In order to be effective, a validator MUST understand all digital signature 
>algorithms marked as MANDATORY and SHOULD understand all digital signature 
>algorithms marked as RECOMMENDED.
>
>REQXX: Validators MUST implement all MANDATORY digital signature algorithms 
>and SHOULD implement all RECOMMENDED digital signature algorithms.
>
>Note: This wording isn't the best, and needs some work. I also don't know if 
>the SHOULD in the REQ should be changed to a MAY, but I would prefer SHOULD. 

Thanks for the suggested text, for the most part I think it is on target.  But 
to hark back to my comment before it, I'd change (for example):

"Validators have to be able to understand and validate different algorithms 
that may be in common use with DNSSEC."

to:

"General purpose validators, in order to be widely adopted and accepted, ought 
to implement as many of the commonly used DNSSEC security algorithms, with 
"commonly" interpreted, at least on one way, to include the DNSSEC security 
algorithms in the IANA registry noted."

...again, wording is loose.

My driving concern is that there may be some folks that have a turn-key 
situation in mind; the IETF famously says it is not the "protocol police."

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to