Re: [dnsext] MAR proposal #1: Algorithm downgrade protection

[Edward Lewis <[e-mail]>]

At 10:24 -0400 4/1/11, Samuel Weiler wrote:
>This is a proposed change in DNSSECbis that arguably changes the 
>mandatory algorithm rules.  I'm posting this as a summary of what I 
>understand some may support, I don't support this change myself. 
>Please post in this thread with your support or lack thereof.
>
>
>In order to provide some protection against algorithm downgrade[1], 
>we're defining a mechanism for zone signers to signal to validators 
>that a SET of algorithms should ALL be checked, when possible, 
>before determining that an answer from the zone is Secure. 
>Specifically, we're overloading the DS RRset to do that signalling.
>
>Validators SHOULD check signatures from all algorithms present in a 
>zone's DS RRset or trust anchors before declaring an answer from the 
>zone to be Secure.  If it is impossible to validate an answer with 
>one or more of those algorithms, the answer SHOULD be treated as 
>Bogus.
>
>This is a subset of the checks unbound was performing that let to 
>the discovery of the problems with .cz's algorithm roll process.
>
>Please post in this thread with your support or objections.

IMHO, algorithm downgrade protection is not a goal of DNSSEC. 
Further, there is no way an algorithm downgrade attack can succeed.

Presuming validation, when a resolver receives an answer section 
containing an RRset matching it's query, a resolver has to determine 
if the data is known to be insecure or is supposed to be secured.

If a signature arrives with the answer, the validator can begin there 
and work towards a trust anchor.  Recalling that the point is cache 
protection and the decisions made by the validator are governed first 
and foremost by local policy a validator can decide to ignore a 
specific algorithm as being suspect or broken.

If we are working backwards - that is up the tree from the answer to 
a trust anchor or forward - from a trust anchor down to the answer, 
there will be a point in which we can get the DS RRset for a zone cut 
from a parent and verify it completely.  In the DS set are the set of 
algorithms available of the zone below for the verifier to reply 
upon.  Again, it's the verifiers call which algorithms to use, not 
the DS set.

 From this the verifier can validate the DNSKEY set of the zone cut's 
corresponding apex.  The reason it can do this is that it has secured 
the DS set's state.  If there is no DS set, then there is an empty 
set of algorithms.  If the DS set has no algorithms useful to the 
validator, empty set.  If the DS set shows a stronger algorithm is in 
use in addition to a weak one, the validator can make a note of that 
(exclude the weak algorithm from what's acceptable).  I.e., it's not 
possible to "sneak one by" the validator by stripping signatures.

Stepping down into the zone, if the zone in question is the answer's 
owner (or has a further zone cut, the same will apply to the 
subsequent DS set), then we can look back at the answer.  What 
signatures are there?  Is it evident that a "necessary one" is 
missing?  The answer is yes, because the validator knows from the DS 
what to expect and the validator knows what it has on hand.

There's no downgrade attack that will get past this point if the 
validator has it's local policy implemented.

It's like saying someone's hall pass is good if it is signed by the 
principal but if the principal didn't object then a teacher can okay 
it.  (A teacher can't veto the principal.)  If the principal checked 
it and denied it yet the teacher signed it, the hall monitor can tell 
- if it is evident that the principal checked it.  If the result of 
the check isn't available, policy should prevent access, regardless 
of the lower level approval, right?

Turning this around - what if the hall monitor saw that the principal 
had approved but there was no word from the teacher?  It's a waste of 
time for the teacher's approval to be sought, because policy says the 
principal rules.  Even if the teacher is supposed to have an approval 
there, the lack if it isn't important.  Holding up the student will 
just irritate the student at that point.

DNSSEC is to protect the cache and it is up to validators to apply 
the necessary policy to meet the goals of DNS and security.  Get the 
answer fast and reliable.  DNSSEC is not about letting zone admins 
dictate to consumers how the zone is secured.  Zone admins are adding 
ancillary data to allow validators to make their checks.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"