Subject: Re: DNSSECbis Q-2: degradation attack

From: Sam Weiler <[email-masked]>
Date: Mon, 1 Sep 2003 11:27:43 -0400 (EDT)

> The problem as I read it from Mike's and Ed's message, is that one
> wants to turn the use of specific algorithms within a zone on or of,
> without imposing requirements on the algorithm used by the parent (and
> having the parent impose algorithms on the child).
...
> The scheme below does not require the algorithms of the parent and
> child to match.  Besides one can use the keys without the SEP bit to
> turn specific algorithms on or off; making the it decidable which
> algorithms to expect.

My scheme doesn't require that they match either.  A parent could have
a DS of type 42 (for the child) signed only by a type 5 (it's own
algorithm choice).  That's fine and dandy.

Olaf's scheme looks similar to mine, but it allows algorithms to be
removed in the DNSKEYset at the cost of assigning protocol semantics
to the SEP bit.  I think it's sufficient to allow algorithms to be
removed at the DSset (they can be added there or in the DNSKEYset).
If we're worried about a malicious parent imposing algorithms, then we
might as well worry about it imposing it's own choice of DS, and not
telling the child what the corresponding DNSKEY is.

So, again, I think the scheme I proposed is sufficient.

-- 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: Mon, 1 Sep 2003 11:21:52 -0400 (EDT)

I'm writing a wrap-up summary, but here is a reply to Mike's comments:

I've been working with the premise that "signing a zone must not make
your zone disappear".  This same constraint that drove the DS lameness
and grandparent problem fixes as well as the type code roll.  If
signing a zone would make it less visibile, there's too much
disincentive to deploy DNSSEC.

On Tue, 19 Aug 2003, Mike StJohns wrote:

> The resolver either understands or doesn't understand an algorithm
> If it understands it, it either trusts it or rejects it. (rejects it
> because its considered broken for ex) If it trusts it, it will
> follow a chain signed by it, otherwise it won't.

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

By the same token, if a client thinks an algorithm is broken, it may
ignore it -- if it would normally pass through unsigned data, it
should still pass through data signed only by the broken algorithm.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Mon, 1 Sep 2003 12:06:25 -0400 (EDT)

It sounds like Olafur and I have different views of the current state
of the world.  It sounds like Olafur thinks clients should already be
enforcing the tighter rules that I'm asking for, or something similar:

> IFF some RRset is only signed with type 42 then any validator that
> does not understand/use that type, will drop this RRset as bad, this
> is the publishers choice.

As I said in response to MSJ, this violates the premise that "signing
a zone must not make your zone less visible".  But if this is the
current state of the world, then my scheme is really a no-op.  It just
clarifies client behavior and tells zone owners how to avoid being
knocked off the net.

To clarify, my logic went as:

1) Signing (or adding a new algorithm) must do no harm -- adding
RRSIGs should not cause a zone to be less visible than before.

2) In the current world (according to the current specs), it's OK to
sign some RRsets with one algorithm, and some with another.

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.

4) #3 allows a degradation attack, which is bad.

And I proposed that we change #2 to deal with this -- specifically
that we say it's not okay to, as Ed puts it, "'turn off' security 'per
algorithm' in a zone".  With that in place, clients can then impose a
stricter set of checks, and the degradation attack goes away.

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

-- Sam

---

From: Miek Gieben <[email-masked]>
Date: Tue, 2 Sep 2003 19:59:12 +0200

[On 01 Sep, @18:06, Sam wrote in "Re: DNSSECbis Q-2: degradation ..."]
> to #1.  If #2 isn't true, then my scheme is a merely a clarification.

i'm re-reading the entire thread to make sure I understand it. And now I do :)
(have to think about the solution though).

But you make one assumption: resolvers will check the zone's status before
validating anything. I have yet to see such resolvers....

Those resolvers just check sigs if they get them. Just spoofing sigs (with 
whatever algorithm) is just as bad.

(I'm not saying I like this method of resolving, i'm just saying that there
already are resolvers working like this. However a bad sig is an indication 
that something is the matter)

grtz Miek

---

From: [email-masked]
Date: Tue, 2 Sep 2003 02:02:28 -0700 (PDT)

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

> sign some RRsets with one algorithm, and some with another.

	yes.

> non-understood type must treat the data as unsigned in order to

	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.

> to #1.  If #2 isn't true, then my scheme is a merely a clarification.

	#1 is not enforceable.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Sep 2003 16:50:42 +0200

> to #1.  If #2 isn't true, then my scheme is a merely a clarification.

Ok, having talked to Sam, he convinced me about this degradation attack.

As I understand it, the following takes place:

There are four distinct cases:

1. there is no DS at the parent. A resolver should treat the 
   child zone as being "verifiably UNsecured".

2. there is DS and the DS points to a DNSKEY with a known algorithm.
   The resolver should treat the child zone is being "verifiably secured".

3. There is a valid DS at the parent, but the DS points to a DNSKEY with a
   unknown algorithm. So there is a DS. The zone should be verifiably unsecured
   not BAD.

You should treat this as unsigned, not as BAD. If you treat this as
BAD it is impossible to deploy new algorithms - the zone deploying 
the new algorithm would drop from the Net immediately.

4. There are 2 DSs at the parent, one which points to a key with an 
   unknown alg. DNSKEY and one that points to a DNSKEY with a known alg. 
   Then in the child zone some RRsets are signed with the known alg. and 
   others with the unknown alg KEY.

With 4. A resolver comes in, sees the RRset, get's the sig. *bam* unknown
algorithm. Now what? Bad? Well actually no - it is just that the resolver
doesn't know the algorithm. This should not lead to a situation were the zone
drops from the Net. If that happens it is impossible to deploy new algorithms
gradually on the Net. (This is the same as what happens in 3.)

The only thing that would help here is if the RRsets are also signed with the
other, known algorithm.

And that is what Sam is saying: 
A zone should be signed with ALL the algorithms in the keyset. And the keyset in
turn should be signed with all the algs. in the DS set. This is currently under
or not specicified in the specs. If a zone is not signed this way a resolver
should raise an error (and not treat the data is being BAD).

regard,
Miek

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 3 Sep 2003 11:23:04 -0400

I think this write-up helps clear the air a bit.  I agree with the threat of
the degradation attack, but there are 2 (possible) task the WG and DNSSECbis
editors should clarify:

1.  Should the DNSSECbis drafts, or some other document, give more
specifications of what a "secure, signed zone" should contain?  In order for
a resolver to be able to make a decision about the security status of a zone
when it gets a response.

2.  Is this threat severe enough to warrant specific language on a secure
zone contents (with respect to RRSIGs) in the DNSSECbis spec, or have it as
a recommendation, as in a BCP?

3. (larger scope) - how resolvers might want to classify responses with
regards to security as well as authority.

With respects to question 2, I'm starting to lean towards BCP for the text.
I believe it is a threat, but not one that most administrators will have to
deal with (most will only sign with 1 algo until told it has been broken).

I'm ambivalent on the topic
Scott

---

From: Miek Gieben <[email-masked]>
Date: Wed, 3 Sep 2003 21:50:07 +0200

[On 03 Sep, @17:23, Scott wrote in "Re: DNSSECbis Q-2: degradation ..."]
> deal with (most will only sign with 1 algo until told it has been broken).

well, I guess it should be specified in the DNSSECbis spec - that way resolvers
can treat it as a "real" protocol error when they encountered it. The attack is
real enough to warrant this. It's not about administrators, it is about being
able to deploy a new algorithm when the need arises.

grtz Miek

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Sep 2003 21:13:09 -0400

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

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:
    Miek> With 4. A resolver comes in, sees the RRset, get's the sig. *bam*
    Miek> unknown algorithm. Now what? Bad? Well actually no - it is just
    Miek> that the resolver doesn't know the algorithm. This should not lead
    Miek> to a situation were the zone drops from the Net. If that happens it
    Miek> is impossible to deploy new algorithms gradually on the Net. (This
    Miek> is the same as what happens in 3.) 

  This is why context is important. That's why the stub resolver and
application are important here.

  The answer as to what to do depends upon the consumer. I.e. the
application. In all cases where we would say "bad", we need to actually say
something more complicated to the application. 

  ||ugh has called this property "quality" of the answer. Since different
applications have different security requirements, they need to be able to
make informed choices. Sure, lots won't, and you need a default for that. But
that itself, is a system-admin defined choice.

]      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: Edward Lewis <[email-masked]>
Date: Wed, 10 Sep 2003 18:25:01 -0400

At 16:50 +0200 9/3/03, Miek Gieben wrote:
>A zone should be signed with ALL the algorithms in the keyset. And the keyset
>in turn should be signed with all the algs. in the DS set. This is currently
>under or not specified in the specs. ..................................

Right.  And, IMHO, the "shoulds" above ought to be MUSTs in the document.

>.................................... If a zone is not signed this way a
>resolver should raise an error (and not treat the data is being BAD).

I admire the effort, but this is impossible.  A client can't 
determine if data is missing at the server if there's a chance the 
medium is stripping the data.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 11 Sep 2003 09:50:54 +0200

> medium is stripping the data.

Huhhh????

But the whole point is that not having SIGs for each algorithm is an
error condition; Off course you do not know what caused the error;
maliciousness, signer error, config error, but there is an error. It
is local policy to the resolver how to deal with that.

-- Olaf

PS. The chairs would like to get this issue closed, say within a week.
Please speak up if you do not agree with the idea that zone data MUST
be signed with all of the algorithms present in the keyset.

Suggestions on the resolver behavior are still welcomed.

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 11 Sep 2003 07:33:22 -0400

Just to clarify (in my own mind mostly):  Strong statement about how a zone
MUST be presented - i.e. with a RRSIG from every algorithm in the zone
signing keyset.  I guess that means protocol document statements.

On the resolver end, local policy will determine if missing RRSIGs might
cause the entire response to be marked BAD, or something else.  It would be
up to the resolver.

Is that seem to mesh?  I'm pretty much restating in order to keep things
clear and (hopefully) resolved quickly.

Scott

---

From: Miek Gieben <[email-masked]>
Date: Thu, 11 Sep 2003 14:19:48 +0200

[On 11 Sep, @13:33, Scott wrote in "Re: DNSSECbis Q-2: degradation ..."]
> signing keyset.  I guess that means protocol document statements.

yes,

> cause the entire response to be marked BAD, or something else.  It would be

yes,

> Is that seem to mesh?  I'm pretty much restating in order to keep things

yes,

> clear and (hopefully) resolved quickly.

let's hope so. I'm in favor of putting (something like) the first paragraph
in the protocol doc,

grtz Miek

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Sep 2003 08:29:23 -0400

>is local policy to the resolver how to deal with that.

    Server has       medium does this        Client gets

Case 1 (The desired case):
       X----------------------------------------X
       Y----------------------------------------Y
       Z----------------------------------------Z

Case 2 (Server doesn't sign with all)
       X----------------------------------------X
       Y----------------------------------------Y

Case 3 (Medium eats one/MIM stips one)
       X----------------------------------------X
       Y----------------------------------------Y
       Z--------------------\

A resolver (besides only being able to judge the set, not whether the 
zone is signed correctly) can't determine if the zone admin did the 
right job (whether the zone is signed correctly).  In the context of 
Miek's message, it appeared be wanted the resolver to flag the zone 
as misconfigured - which is something a client cannot do.  (In case 
3, it looks like the zone is misconfigured, but it isn't the server 
side's fault.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Miek Gieben <[email-masked]>
Date: Thu, 11 Sep 2003 14:51:46 +0200

[On 11 Sep, @14:29, Edward wrote in "Re: DNSSECbis Q-2: degradation ..."]
> 3, it looks like the zone is misconfigured, but it isn't the server 

I agree that a resolver cannot distinguish between a wrongly signed zone
and a network hiccup which causes sigs to disappear. So I should have
said: flag it as an error (not a misconfiguration).

grtz Miek

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Sep 2003 09:10:07 -0400

>said: flag it as an error (not a misconfiguration).

Yeah - or as something "to be reported."  In general Internet usage, 
feedback to the server via some other means isn't a consideration. 
But there might be private applications that would.

Odds are that this isn't a problem that would go away with a retry. 
Parts of packets don't just "disappear" without a little help.

---

From: Sam Weiler <[email-masked]>
Date: Thu, 11 Sep 2003 09:36:29 -0400 (EDT)

On Thu, 11 Sep 2003, Scott Rose wrote:

> Just to clarify (in my own mind mostly):  Strong statement about how
> a zone MUST be presented - i.e. with a RRSIG from every algorithm in
> the zone signing keyset.  I guess that means protocol document
> statements.
>
> On the resolver end, local policy will determine if missing RRSIGs
> might cause the entire response to be marked BAD, or something else.
> It would be up to the resolver.

Some client rules are needed, namely that a zone MUST be treated as
unsigned if only unsupported algorithms are in the DSset.

I've been trying to refine the text I posted on 13 August.  Here's
that text, as background:

>   Every RRset MUST be signed by at least one DNSKEY of each
>   algorithm in the DSset and each additional algorithm, if any, in
>   the apex DNSKEYset.  The apex DNSKEYset itself must be signed by
>   each algorithm appearing in the zone's DSset.
>
> And the implications for a validator:
>
>   1) If the only algorithms in a DSset aren't ones you understand,
>   you may treat the zone as unsigned (as things are now).
>
>   2) If there are algorithms you grok in the DSset, but the only
>   algorithms signing the DNSKEYset are ones you don't understand,
>   you should assume something bad is happening.  (this is a change)
>
>   3) And if there are algorithms you grok in the DSset and
>   DNSKEYset, but the only signatures on some RRset are made with
>   algorithms you don't understand, you should assume something bad
>   is happening (this is a change).

The first paragraph above (re: zone contents) is good verbatim, I
think.

Here's the new stuff re: resolver behavior.

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

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

   When a supported algorithm appears in a zone's DSset but not in its
   apex DNSKEYset, a resolver SHOULD NOT treat the zone as unsigned.

   Alternative text for #2 might say: A resolver SHOULD treat the
   absence... as a validation failure.  But that doesn't deal with the
   case where some signature chain did validate.  If any signature
   chain validates, everything else (dropping algorithms that appeared
   in the DSset from the DNSKEYset, not getting RRSIGs of all
   algorithms (algorithms, not DNSKEYs)) is irrelevant.

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 11 Sep 2003 09:58:29 -0400

----- Original Message ----- 
From: "Sam Weiler" <[email-masked]>

*snip*

> The first paragraph above (re: zone contents) is good verbatim, I

I agree.  If the concensus is to put this in the protocol document, I will
abide.  I agree about the text, and have no strong feelings about where it
should be placed (spec or BCP) as long as it appears.

>    When a supported algorithm appears in a zone's DSet but not in its

The first SHOULD in 2) seems out of place.  I can't see how 2119 language
should be used to tell a resolver what it should expect to see in a
response, just how to deal with it.  I believe that if the resolver cannot
get a security statement from the verifier (ie cannot verify all or part of
an response), it should treat the data as "unsigned" and go from there accor
ding to local policy.

>    algorithms (algorithms, not DNSKEYs)) is irrelevent.
>
>

---

From: Sam Weiler <[email-masked]>
Date: Thu, 11 Sep 2003 09:28:45 -0400 (EDT)

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

---

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

On Thu, 11 Sep 2003, Scott Rose wrote:

> response, just how to deal with it.

It probably is out of place.  The alternative text is probably must
easier to understand.

> I believe that if the resolver cannot

Are you distinguishing between "I got a chain of trust that I should
be able to verify (I support all the algorithms and have a configured
root of trust), but it didn't" and "I didn't expect this zone to be
signed"?  This whole problem falls of from thinking that resolvers
will have at least three cases, not all of which are the same:

1) The data is signed and validated.  Yippee.

2) The data isn't supposed to be signed.  Perhaps I lack a root of
trust.  Perhaps the delegation to the child (or one of its parents)
lacks a DS, confirmed by a signed NSEC.  Perhaps the only DS is for an
algorithm I don't understand.

3) The data is supposed to be signed, but something broke.  Maybe the
RRSIG just didn't validate.  Maybe there was a DS at the parent, but
no DNSKEYset in the child.  Maybe there was a DS (of a supported
algorithm) at the parent, but no matching DNSKEY in the child.  Maybe
the RRs weren't signed with the algorithm I understand (and that
appeared in the DNSKEYset).

In case 2, some clients might reject all unsigned data, but I suspect
most won't.

In case 3, current clients give very hard failures.  That probably
needs to change slightly.  (ie. What if the thing that broke was the
trust root (my preconfigured key didn't match the one in use), and
everything below it validated?  I might want a softer failure mode.)

But under the assumption that most clients still give answers in case
2, treating case 3 as unsigned (case 2) makes me wonder why we're
doing DNSSEC at all.  If we're just going to give the same answers no
matter which of case 1, 2, or 3 happened, why bother?

Going back to the issue at hand, if clients expect a zone to be
signed with any, but not all, of the algorithms, then they don't have
enough information to decide if "the RRs weren't signed with the
algorithm I understand" is case 2 or case 3.  And routinely treating
it as case 2, which I think is necessary to satisfy the safety
property, opens the door to a degradation attack.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 24 Sep 2003 16:59:53 +0200

Colleagues,

I reviewed the thread on the "degradation attack" to see if there is
consensus.

Althought there were some off-topic digressions I think it is fair to
conclude that Sam's proposal 'to make verification with all algorithms
in the keyset mandatory' has support. Please speak up and motivate if
you do not agree. I'd like to close this issue by the end of the week.

For the most recent and detailed proposed text:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01735.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01736.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01745.html

More discussion in that same threat.

-- Olaf Kolkman
   DNSEXT Co-Chair

PS. This is relevant to the question I just posted on "DNSSEC-RECORDS
ISSUE: DSA from Mandatory to Optional". With the possibility of a
degradation attack it is difficult to introduce other algorithms
without being vulnarable to the attack which inspired the above
thread.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 16:45:11 +0000

> I have not seen a counter argument against Roberts statement that
> caches and authoritative servers will behave differently when a cache
> has previously stored the result of a QTYPE=CNAME query. 

i think the clarification that bears on that point is that
wildcard-synthesized data should have TTL=0 to prevent caching.