Re: [dnsext] Clarifying the mandatory algorithm rules

[Edward Lewis <[e-mail]>]

>"It seems like you are favorable towards the validator verifying an RRSIG
>for every algorithm (which it understands, of course) that exists in the
>DS RRset."

No, no, no, quite the opposite.  For any given resource record set, a 
validator ought to try algorithms until any one works. Same for 
signatures and keys.

I can't think of any situation in which DNS should do "everything". 
It is a "do something" protocol, not a "do everything" protocol.

The goal is "get the answer to the client" not "ensure security is followed."

Maybe the situation is unclear.

First, when obtaining an answer, DNS is mostly done as it was without 
DNSSEC, i.e., depth-first to the answer.  The "mostly" means that in 
addition to this depth-first plunge, DNSSEC records are also held.

If the answer has a signature and the answer is below a trust anchor, 
then walk backwards from the answer to the trust anchor.  That means 
starting with the answer's RRSIG's signer identifier.  Then validate 
the signer identifier and so on.  If there is ever a choice, again, 
default to a depth-first strategy to find the first chain that can be 
built.  If no chain can be built, the reason will determine if the 
situation is a service failure or an explicitly broken chain.

If the answer has no signature, then you need to first determine if 
there is a need to find one.  Starting with the appropriate trust 
anchor, go depth first towards the answer.  The dive is from zone to 
zone, looking for an unbroken chain.  If a delegation as no DS record 
set, then DNSSEC "stops."  If a delegation has a DS record set but no 
algorithm is understood by the validator, then DNSSEC "stops."  If 
the delegation has a DS record set with one algorithm that is 
understood, the next zone is signed in just that algorithm and is why 
each set has to have each algorithm.  If the delegation has a DS 
record set has a number of useable algorithms...just pick one, try 
it, if not, try another, and so on.

DNS/SEC has to have a depth-first, goal-oriented search.  It is not a 
navel-gazing, breadth-first search.  There's nothing wrong in 
pre-fetching, fleshing out the tree's trustworthiness, and other 
activity, but that shouldn't be critical path when answering a 
question.


At 11:18 -0700 3/16/11, Casey Deccio wrote:
On Tue, Mar 15, 2011 at 5:45 AM, Edward Lewis 
<<mailto:[e-mail]>[e-mail]> wrote:

The specification requires the generation of a signature of each 
algorithm in the DS record to set the expectation of the validator 
(remote end).  The expectation is that if the DS record set indicates 
that algorithm X is in use, there will be a signature of algorithm X 
to be had.  If this expectation is not met, then the validator is to 
declare a protocol failure.


For further clarification...  It seems like you are favorable towards 
the validator verifying an RRSIG for every algorithm (which it 
understands, of course) that exists in the DS RRset.  Is this 
verification just for the RRSIGs made by SEP (i.e., corresponding to 
DS RRs) DNSKEYs covering the DNSKEY RRset, or for any arbitrary RRSIG 
in the zone?  If the former, once you have authenticated the DNSKEY 
RRset (with all the algorithms in the DS), then an RRSIG may be 
verified by any DNSKEY in the DNSKEY RRset, regardless of algorithm; 
if the latter, then the algorithms must play a part in validating any 
RRset in the zone.  The former seems more reasonable to me.  It seems 
like perhaps your view has changed from SHOULD NOT to SHOULD in one 
of these regards?

In either case, I think that a bit more wording should be added to 
the proposed text to make it clear what is expected of the the 
validator, in terms of which RRSIG to check algorithms for, depending 
on what consensus is.

Casey


_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at [phone]

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"