Re: [DNSOP] [Ext] comments on draft-mglt-dnsop-dnssec-validator-requirements-05

[Daniel Migault <[e-mail]>]

Hi,

Thank you for the feed backs Scott. We will address them in the next
version.

The motivation for crypto deprecation is clearly to follow the crypto
recommendations stated by the IETF. However, this requirement for the
validator is to actually "validate" those requirements are effective. The
intent is clearly not to overcome the crypto recommendations.  But you made
a good point, and we will address this.

Yours,
Daniel

On Wed, Jul 19, 2017 at 5:01 PM, Edward Lewis <[e-mail]>
wrote:

>
> On 7/19/17, 08:49, "DNSOP on behalf of Rose, Scott (Fed)" <
> [e-mail] on behalf of [e-mail]> 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."
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>