Subject: Re: DNSSEC and unknown algorithms

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Dec 2004 08:07:12 +1100

> 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    <[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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: David Blacka <[email-masked]>
Date: Thu, 16 Dec 2004 16:54:44 -0500

Wes Hardaker wrote:
>>>>>>On Thu, 16 Dec 2004 15:34:51 -0500, David Blacka <[email-masked]> said:
> 
> 
> David> In protocol-09, section 5.2, there are two paragraphs
> David> describing what to do when a resolver encounters a delegation
> David> to a zone signed only with unknown algorithms:
> 
> proto-09-5.2> If the validator does not support any of the algorithms
> proto-09-5.2> listed in an authenticated DS RRset, then the resolver
> proto-09-5.2> has no supported authentication path leading from the
> proto-09-5.2> parent to the child.  The resolver should treat this
> proto-09-5.2> case as it would the case of an authenticated NSEC RRset
> proto-09-5.2> proving that no DS RRset exists, as described above.
> 
> If you follow the advice in that last sentence, doesn't it allow for
> someone to craft a DS packet with a unassigned algorithm ID and send
> it to the requester and they'll actually immediately treat that packet
> as a proof of non-existence?  Why would you ever treat a response you
> can't authenticate as an authenticated NSEC?  Treating it as an
> unauthenticated NSEC I can understand, but not as an authenticated
> one.

No.

This is actually discussed earlier in section (5.2).  The validator is 
working with verified DS records from the parent.  I.e., the parent is 
signed with a known algorithm.  So you aren't making a security decision 
based on unauthenticated data here (which is what I'm worried that some 
misguided implementation might do).

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 17 Dec 2004 08:57:21 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of David Blacka
>
I think it was a decision to defer to local policy.  Some sites may wish to
shoot themselves in the foot.  If a validator sees a DNSKEY with an algo it
doesn't understand, it may still be able to verify the parent's RRSIG
covering the DS, so a smart validator would determine "signed by something I
can't verify":  and it's up to local policy to how that response is handled.

Scott

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 16 Dec 2004 13:26:43 -0800

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 17 Dec 2004 12:18:26 -0500 (EST)

> does the resolver actually have except to treat the zone as unsigned?

Maybe the resolver could still check to see if all RRsets still have
unexpired RRSIGs of an appropriate algorithm type, even if the crypto
bits don't work?  It shouldn't set the ad bit if an answer passes
those checks, but it might throw an error if they fail.

As the author of text that led to these paragraphs, I don't recall
exactly why I didn't use a 2119 MUST.  In general, I think 2119 MUSTs
should be used sparingly, and only with known good reason.  If there's
any plausible non-offending alternative, a SHOULD is more appropriate.

> do the typecode rollover in the first place?

TCR happened because some (widely deployed) resolvers treat any answer
with an NXT being as being a denial of existance, no matter the name
bounds of that NXT.  Since DS added NXTs to positive answers (unsecure
referrals), unsecure delegations from signed zones didn't work.  I
don't know if we ever tested what happened to other NXT-bearing
positive answers (i.e.  wildcard answers), but this was sufficient to
justify the TCR.  Jakob discovered the bug on New Years' Eve, two
years ago.  Mark Andrews tracked it down the next day.

To answer David's question, no, the use of unvalidated data is not
what triggered the TCR.  I don't recall whether an unvalidated NXT is
sufficient to trigger the bug above -- it might be, but that wasn't
the reason for the TCR.

-- Sam