RE: DNSSEC and unknown algorithms

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

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: owner-namedroppers@ops.ietf.org 
> [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of David Blacka
> Sent: Thursday, December 16, 2004 3:35 PM
> To: namedroppers@ops.ietf.org
> Subject: DNSSEC and unknown algorithms
> 
> 
> 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    <davidb@verisignlabs.com>
> Sr. Engineer    VeriSign Applied Research
> 
> --
> to unsubscribe send a message to 
> namedroppers-request@ops.ietf.org with the word 'unsubscribe' 
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 

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