Subject: Re: DNSSECbis Q-2: degradation attack

From: Samuel Weiler <[email-masked]>
Date: Tue, 2 Sep 2003 10:21:51 -0400 (EDT)

[Resending this, since tislabs.com seems to have trouble sending mail to 
namedroppers.  Sorry for the duplicate, if any.]

> > > the resolver may also impose certain minimums on things like key
> > > length to determine trust/reject?
> >
> > A client may certainly do this, but only if it would also reject
> > unsigned zones.  For example, you might say "I'll only accept DNS data
> > signed by 1024+ bit RSA/SHA-1 keys".  Dandy.  Then a zone choosing to
> > sign only with DSA is no less visible to that client than if it were
> > unsigned.  The danger comes when signing with 512 bit RSA/SHA-1 leaves
> > you inivisible where you weren't before.  We should prohibit clients
> > from doing that, to keep from providing disincentives to signing.
>
>       say what?  just how are you going to enforce this prohibition?
>       are you proposing that a client may not create a local policy
>       that states "if its not signed, it doesn't exist"?

What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1
keys'.  Dandy." didn't you understand?

Sure, a client may create that policy.  The policy I want to prohibit
is: "I won't accept any signed DNS data; I'll take unsigned data only;
if you sign your zone, you lose."  This, and its variants, violate the
safety property, and just like the (unintended?) policy of treating
all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC.

How do I plan to "enforce" it?  By publicly humiliating client authors
who do something different, much as we like to publicly humiliate
clients that don't do negative caching.  We can't keep clients from
shooting DNSSEC in the foot, but we can keep from writing a spec that
gives them a hunting license.

-- Sam

--
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: Sam Weiler <[email-masked]>
Date: Tue, 2 Sep 2003 08:07:14 -0400 (EDT)

-- Sam

---

From: [email-masked]
Date: Tue, 2 Sep 2003 01:56:47 -0700 (PDT)

---

From: [email-masked]
Date: Tue, 2 Sep 2003 07:22:55 -0700 (PDT)

> keys'.  Dandy." didn't you understand?

	you are not being consistant here.  your statement above indicates
	the clients are expected to have a local policy, and then you
	make the claim, on behalf of the server operators that "We should
	prohibit clients..."  You can't have your cake and eat it too.

> all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC.

	We either get to let client set policy or not. Scoping
	the policies that are "allowed" is presumptious for zone
	admins, -if- it is expected to be a client activity.
	
> gives them a hunting license.

	If you want a fixed policy, then don't let the clients
	set one. They just eat what the servers say. Thats the
	only enforcement tool you get.  If you open up policy 
	for clients to set, then your only choice is to tell them
	the outcome of certain choices, some of which will hurt them.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 18:46:05 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:
    Miek> [On 02 Sep, @23:16, Michael wrote in "Re: DNSSECbis Q-2: degradation ..."]
    >> Mike, thank you for the diagram. It looks correct to me.
    >> It certainly answers the algorithm question for me.
    >> 
    >> A major question is what does the resolver do with all this information?
    >> 
    >> One thing I found weird about your diagram is that you have "Process Normal
    >> Response" in the middle of the diagram, while "Treat Secure" is at the
    >> bottom. 
    >> 
    >> It isn't obvious that the "Treat as Bogus" is also a terminal node. May
    >> I suggest that you put them all at the bottom of the diagram?
    >> 
    >> Then, we are back to the problem of expressing three outcomes using only
    >> 1 bit when communicating with the application :-)

    Miek> is there any documentation about this API? Should I look at the
    Miek> lwred source code from bind9? Or are we free to invent a new API?

  lwres is built into bind9.
  It is presently just DNS over 127.0.0.1:953. I would actually prefer to
use Unix domain stream sockets - specifically so that I know that it is
local, and so that I can get signaled when the server dies, etc.

  I have just finished (yet another?.. not quite) async interface to
liblwres, which I'm about to post. It groks DNSSEC and follows CNAMEs,
which I need.

  Please note reply-to.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 18:49:24 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Mike" == Mike StJohns <[email-masked]> writes:

    >> A major question is what does the resolver do with all this information?

    Mike> That's another RFC.... "An application's view of DNSSEC"...:-)
    Mike> Seriously  
    Mike> though,  I'd be happy just to get the resolver to the secure, bogus, 
    Mike> insecure state and then map that answer with the question against

  Not enough.
  We have been down this route. 

  When it breaks, we get "SERVFAIL". There aren't very many people who can
diagnose the problem, even with resolver logs. Solution? Turn off DNSSEC.
  For this reason alone, we have to do better than this.

    Mike> sorting algorithm... such algorithm is left as an exercise for the
    Mike> reader. 

  I beg to differ. It might seem easy, but it isn't.
  It is critical that we do this right. Otherwise, DNSSEC gets turned off
because we can't distinguish two of the cases.  

    Mike> Yeah...I need to look at what bind and other things do here...

  Not lots yet.

---

From: [email-masked]
Date: Wed, 03 Sep 2003 13:48:07 +1000

> > 1) Signing (or adding a new algorithm) must do no harm -- adding
> > RRSIGs should not cause a zone to be less visible than before.
> 
> 	you, as zone owner, have one choice, to sign or not.
> 	you can't infer client behaviour when they are presented
> 	with this choice.  You may recommend specific actions
> 	as desirable for a particular outcome, but thats about
> 	as far as you can go.
> 
> > 2) In the current world (according to the current specs), it's OK to
> > sign some RRsets with one algorithm, and some with another.
> 
> 	yes.
> 
> > 3) A client that comes across an RRset with an RRSIG of only a
> > non-understood type must treat the data as unsigned in order to
> > reconcile #1 and #2.
> 
> 	if and only if thats the local resolver policy.
> 	you have at least one unstated presumption here.
> 
> > 4) #3 allows a degradation attack, which is bad.
> 
> 	sort of.
> 
> > >From the sound of Olafur's and Miek's messages, they don't believe one
> > of #1 or #2, and I'm not sure which.  Either way, I'm pretty committed
> > to #1.  If #2 isn't true, then my scheme is a merely a clarification.
> 
> 	#1 is not enforceable.
> 
> > 
> > -- Sam
> > 
> > --

	If a zone is not signed with *a* manditory to implement
	algorithm it is a operator error (this assumes the Internet
	name space).  It doesn't have to be signed with all manditory
	to implement algorithms.

	A parent and child can choose to use different manditory
	to implement algorithms.  This does NOT break the chain of
	trust.

	If a answer comes in w/o a algorithm you understand then
	you drop the answer and wait for the real answer to arrive.
	You should be waiting anyway in case the first response is
	bogus.
	
	If a resolver has disabled a manditory to implement algorithm
	and that is all that is there then they can't resolve the
	zone.

	If a resolver says that some algorithm must be there and
	it isn't then again the zone cannot be resolved.  One would
	assume that when one tells a resolver this that the operators
	have some knowledge that would lead them to believe that
	this is a reasonable restriction of part/all of the namespace.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 03 Sep 2003 09:31:04 +0200

* Then, we are back to the problem of expressing three outcomes using only
 * 1 bit when communicating with the application :-)

Although important this issue is out of scope for this particular thread.

--Olaf
  DNSEXT Co-chair

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Sep 2003 00:10:41 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Sam" == Sam Weiler <[email-masked]> writes:
    Sam> Here's the new stuff re: resolver behavior.

    Sam> 1) A resolver that supports none of the algorithms in a zone's DSset
    Sam> MUST treat the zone as unsigned.  (Implicitly, if the resolver, by
    Sam> policy, insists on signed data, that's fine -- a zone signed only by
    Sam> unwanted/unsupported algorithms is still treated the same as an
    Sam> unsigned zone.)

  i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't exist for
me.

    Sam> 2) If a resolver supports one or more of the algorithms appearing in
    Sam> a zone's DSset, it SHOULD expect every RRset in the zone to be
    Sam> signed.  The resolver SHOULD NOT treat an RRset as unsigned just
    Sam> because it lacks an RRSIG made by any algorithm it supports, so long
    Sam> as that algorithm appeared in the zone's DSset or DNSKEYset.

  so, if the entry point is made with a algorithm I support, but the RRsets
are done with another algorithm, then ??? 
  I'm not clear I understand the text for this case.

---

From: Sam Weiler <[email-masked]>
Date: Fri, 12 Sep 2003 07:09:05 -0400 (EDT)

On Fri, 12 Sep 2003, Michael Richardson wrote:

>   i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't
> exist for me.

Yup.  (s/DNSSIG/RRSIG/)

>   I'm not clear I understand the text for this case.

The new rule is that if the entry point includes algorithm A,
algorithm A must be used to sign the whole zone.[1]  So, by these
rules, the zone is not properly signed, and the resolver SHOULD treat
this an a validation error.[2]  With the current BIND behavior, it
would give a SERVFAIL and no answer.  That's not ideal, but it's the
best we have today.

Another way to look at the change is that we needed to find a way for
the zone to tell resolvers which algorithms it's used to sign a given
RRset.  Rather than add a new signaling mechanism, this change assigns
additional semantics to the DSset and DNSKEYset.

-- Sam

[1] With DSsets and DNSKEYsets, it's a little more complicated than
this -- look at the text I posted yesterday morning.  And, of course,
you can switch DNSKEYs, so long as some DNSKEY of the algorithm is
used for every RRset.

[2] Like the "alternative" text from yesterday, this doesn't deal with
the case of "I found another valid signature chain for this RRset".

---

From: [email-masked]
Date: Fri, 12 Sep 2003 09:55:44 -0700 (PDT)

> >   i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't

	again, I am a bit confused.  (sam, feel free to take me in a corner
	and gently persuade me)   w/ DNSSEC, individual rrs are bound
	into "atomic" rrsets.  you seem to be intimating that if part of
	an rrset is unknown/opaque to me as a resolver, I have the
	obligation to split the rrset back into indvidual rrs and toss
	those bits I can't parse and then (possibly) reassemble the rrset
	with the bits I can parse?  is that -really- what you are suggesting?

--bill