Subject: DNSSEC and unknown algorithms

From: David Blacka <[email-masked]>
Date: Thu, 16 Dec 2004 15:34:51 -0500

I do realize that this topic was probably discussed as nauseum, and this 
comment is extra-super late, but...

In protocol-09, section 5.2, there are two paragraphs describing what to 
do when a resolver encounters a delegation to a zone signed only with 
unknown algorithms:

    If the validator does not support any of the algorithms listed in an
    authenticated DS RRset, then the resolver has no supported
    authentication path leading from the parent to the child.  The
    resolver should treat this case as it would the case of an
    authenticated NSEC RRset proving that no DS RRset exists, as
    described above.

and

    If the resolver does not support any of the algorithms listed in an
    authenticated DS RRset, then the resolver will not be able to verify
    the authentication path to the child zone.  In this case, the
    resolver SHOULD treat the child zone as if it were unsigned.

(sort of redundant to have both paragraphs, but whatever)

My question is, why is this a SHOULD (or "should" in the first 
paragraph).  I suppose I'm imagination impaired, but what other option 
does the resolver actually have except to treat the zone as unsigned?

In my mind, and I may be missing something, if a resolver does not treat 
the zone as unsigned, it will be making validation decisions based on 
unverified data.  Which, I think, is a bad idea.  My memory is a bit 
hazy on the subject, but wasn't it that sort of thing that caused us to 
do the typecode rollover in the first place?

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 16 Dec 2004 14:59:24 -0800

Well one point that really does need to be made clear here that we messed up
on big time in S/MIME is that applications SHOULD treat the zone no worse
than if it were unsigned.

So if there is a policy that says it is signed with X and it is signed
instead with Y then treating it as unsigned still leads to the same error.

What we need to avoid are the pathalogical cases that are inflicted in
SMIME, eg WARNING THIS EMAIL IS SIGNED DO YOU WANT TO OPEN IT? Which appears
when certain email clients receive S.MIME signed email.

Telling people to not penalize people who provide security may sound obvious
but the fact that they did it wrong is why we are now redoing email
signature for the fourth attempt.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Blacka
> Sent: Thursday, December 16, 2004 3:35 PM
> To: [email-masked]
> Subject: DNSSEC and unknown algorithms
> 
> 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.