Re: [dnsext] Validator assumptions: what algorithms need to properly sign a zone?

[Edward Lewis <[e-mail]>]

At 11:42 -0400 3/23/12, Olafur Gudmundsson wrote:

>Both positions are arguable, but it is bad for resolver vendors to 
>be put in this position to argue with customers why they disagree on 
>the right answer, and DNSSEC operators need a strong message what is 
>allowed.

I disagree.  There should be no argument.  A validator needs to be as 
liberal as possible in building a secure "chain" to a trust anchor. 
Liberal means using as many valid options as possible including 
jumping algorithms.  Liberal does not mean bending the rules, 
accepting invalid signatures nor accepting expired signatures.

The reason for the need to be liberal is that DNSSEC is an "add on" 
which inherently makes the underlying system more brittle.  By 
declaring once valid states of the DNS protocol to be dead states 
(SERVFAIL) DNSSEC is choking off parts of the protocol.  To correct 
for that, at least in the name of reliability, resiliency, and 
availability, DNSSEC has to be as liberal (rugged is another word) as 
possible.

Looking at the example, the A2 signatures would be consider not 
germane by any validator that lacks an A2 trust anchor that was the 
key doing the A2 signing.  The lack of A1 signatures would mean any 
validator could rightly assume that something removed the signatures 
("rightly assume" is not equal to "be right in assuming") and treat 
the response as suspect/invalid *if not* for the presence of a valid 
chain via the B1 algorithm.

A valid chain is harder to construct that an invalid one.  Make it it 
harder for a malicious agent by recognizing that fact.  Don't make it 
trivial to cause a denial of service.

>In the case of a validator that supports A but not B SERVFAIL is the
>right answer as the zone is not properly signed for that algorithm.

That is true.  In this case, the validator's failure to speak 
algorithm B is a testament to a lack of ruggedness.

>Some people in this working group have argued that use/order of algorithms
>should be local policy and it is outside the documents scope to talk about
>this, others argue that will lead to unpredictability in resolution status.

Everything is trumped by local policy.  And if local policy is not 
rely on an algorithm, that is a fact of life.   DNSSEC does not 
guarantee the data will get though, it guarantees that is what is 
received can be tested.  (Positive, validation isn't guaranteed, just 
that the receiver will have the means to test.)

>Doodle poll available at:
>	http://www.doodle.com/7v5vmzvaerb2n8sb

Filled in the poll, but still reject voting. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext