[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 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?

	The security policy may say otherwise.

	Say you have a policy that says "Every zone beneath example.net will
	be signed with algorithm A" and example.net is only signed with
	algorithm B.

	Treating the zone as unsigned would be a violation of that
	policy.
 
> -- 
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--
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/>