Subject: Same-signed keys

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Sep 2000 11:17:40 -0400

Earlier in the month, a couple of DNSSEC workshops were held in Europe.
One of the issues was whether the following is possible:

The zone:

         $origin somedomain.xy
         @       SOA
                 KEY    key #1
                 KEY    key #2
                 SIG    KEY by key #1
                 SIG    KEY by key #2
         data    A      address
                 SIG    A by key #2
(and all the other needed records)

The distributed key is key #1 (NOT #2).

When the A record for data is received, here is the chain of trust:

          data A is secured by SIG(A) signed by key #2
          key #2 is secured by SIG(KEY) signed by key #1
          key #1 is implicitly trusted because it is configured in resolvers

This seems like a plausable way to "privately" (old term) or "locally"
(newer term) secure a zone.  But there is one problem, BIND 9(rc5 at least)
enforced a rule that a key set must be signed by a name at least one label
shorter that the owner's name.   The reason - to make sure the chain of
trust progresses to the root at each step.

Brian had the following idea, and I figured it needed to be aired out in
the mailing list.

There is a clear reason to allow key #1 to sign key #2 and for the above
example to work.  There is also a clear reason to prevent arbitratily long
chains of trust to be imposed on resolvers.  To mediate this, the rule of
short names signing longer names will stand with the exception that for a
resolver, at preconfigured points of trust (e.g., key #1's owner), keys of
the same set may be used to validate the others - i.e., an exception to the
"always shorter" rule.

This seems to be acceptable to me.  Comments?

PS - This should be reflected in the signing authority draft.

PPS - The rules regarding who can sign for what say that signers must be <
or = to the length of the data, hence the BIND s/w is overly restrictive as
far as the spec is concerned.  However, the restriction is well-intentioned
as it makes sense that the signer of a keyset is always <
(label-depth-wise) the owner of the key set except at locally
pre-configured points.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 19 Sep 2000 11:55:42 -0700

Is there a technical reason to "prevent arbitratily long chains of trust to be 
imposed on resolvers"? I think I understand the reasons why this is 
suboptimal, and can require a significant increase in computational effort and 
number of queries. I don't see why this needs to be prevented. I do remember 
specific reasons to prevent have a sig that is not in the same tree, and I 
think that prohibition should remain in place. This case does not violate that 
problem.

What it seems to me a better solution is to relax the test such that the test 
is for keys that are at the same level or closer to the root.

jerry

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 19 Sep 2000 15:41:14 -0400

*snip*

> This seems to be acceptable to me.  Comments?

I agree.  Since incremental deployment is an issue, a need for providing a
means to "locally" or "privately" secure zone exists.  If I remember, the
CAIRN testbed used to have a KEY signing key that was statically configured
having the name "cairn.net".  This was different than the cain.net key used
to sign the cain.net zone.

The most obvious threat to allowing signers name = KEY name is the creation
of KEY chains like CNAME chains.  Perhaps keys with the same name length as
the data to be verified should only be allowed if the key is statically
configured?

Just an idea, there is some good and bad "wiggle room" in the RFC.

Scott
===============================================================
Scott Rose
Advanced Network Technologies Division
NIST

ph: 301-975-8439                       fax: 301-590-0932
http://www.nist.gov
===============================================================

---

From: Rob Austein <[email-masked]>
Date: Tue, 19 Sep 2000 16:02:11 -0400

I don't see why this situation is fundamentally different from all the
other forms of potential infinite loops in DNS (eg, CNAME loops).  The
traditional solution is a simple counter (RFC-1035, p43, last
paragraph).  If the only issue here is preventing infinite loops, I
don't think that either form of the "always shorter" rule is necessary
or desirable.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Sep 2000 16:39:23 -0400

The only fundamental difference (if that) is the expense of each operation.

Are you suggesting that the BIND code should just make sure the signer
label length is <= (as opposed to strictly <) the owner length?  (As the
current specs require.)

>don't think that either form of the "always shorter" rule is necessary

I think that there is another fundamental issue here though, that is either
tangential or orthoginal.  Preventing loops is one issue, but so is
"authorization" - the "right" to sign / authenticate data.  This latter
issue is what is driving Signing Authority (close to be moved through the
IESG).

There's a subtle difference between urging BIND to:

1) Only enforce the <= rule

and

2) Not enforce the < rule

The difference is that with #2, "on-tree" validation checks are still done.

PS - The reason that "sideways" authentication is only allowed at
preconfigured points is that this is the only situation in which it makes
sense.  E.g.:

At parent: key #0
At child: key #1, #2.

Child signs zone with #2, distrbutes #1.  But also, child sends keys to
parent for authentication, so {#1,#2} are both signed together by #0.

Upon validation, a resolver could have data->key #2->key #1->key #0.  More
likely, the resolver would see either data->key #2->key #0 or data->key
#2->key #1.  In the latter situation, key #1 would be preconfigured, in the
former, it is not.

I hope that resolvers prefer to shorten the key chaining effort (e.g.,
using preconfigured keys over climbing further)...

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Sep 2000 16:22:20 -0400

At 2:55 PM -0400 9/19/00, Jerry Scharf wrote:
> Is there a technical reason to "prevent arbitratily long chains of trust
> to be >imposed on resolvers"?

Yes.

Ohh, umm, I figure I should back that up, huh...

W/o such prevention, a clogging (DOS) attack could be launched by simply
getting someone to query for data signed by a key that is signed by another
and another and another ... possibly into an infinite loop of
authentications.

Crypto operations are a great amplification-of-effort tool that an attacker
may use to leverage the amount of damage that can be caused.  We want to
limit the number of "free" crypto operations available to arbitrary data.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Sep 2000 22:47:25 +0200

At 11:17 19/09/2000 -0400, Edward Lewis wrote:
>To mediate this, the rule of

it is not possible to deduct that a node in the DNS tree is or is not a 
preconfigured point of trust by looking at it - because this configuration 
is not stored in the DNS.

However, it seems harmless to me to say that self-signed keys are allowed - 
that is, the subject and the name of the key are the same.
This particular infinite loop is always closed after one hop....easily 
checked for; applications that don't have trust in this key preconfigured 
MUST ignore this SIG when deciding whether to trust the key.

          Harald

              Harald

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 19 Sep 2000 17:10:05 -0400

>don't think that either form of the "always shorter" rule is necessary

No, the main issue is:
Do we need to explicitly state that pre-configured trusted keys are
allowed to validate the key set they belong to?

RFC2535 and Signing-Authority do not clearly address this.
The general rule is that KEY set is allays signed by it's parent with
the exception off the root key set.

I think we should allow this as it will make it simpler to create "islands
of security" and assists in initial roll out of DNSSEC.

Off tree validation is a separate topic.

         Olafur

---

From: [email-masked]
Date: Wed, 20 Sep 2000 09:46:12 +1100

> don't think that either form of the "always shorter" rule is necessary

	Supporting looping at the same level helps with really large
	zones or where very long lived keys are required as it can
	reduce the amount of clear text available per key.

	DNSSEC has only defined heirachical securing of zones.  PGP
	style is not defined though it may at somestage be useful
	at some point in time.  Have a knob that defaults to enforcing
	the heirachical nature is one way to go.

	Note this looping is within one RRset so it should be easy to
	detect infinite loops.  With PGP style securing of zone it
	becomes harder but not impossible as the loops are potentially
	bigger.
	
	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian Wellington <[email-masked]>
Date: Tue, 19 Sep 2000 16:20:41 -0700 (PDT)

> is not stored in the DNS.

It's not possible to tell as an outsider.  However, a resolver knows
whether or not it has the preconfigured key.  If it does, the validation
can be attempted.  If not, it cannot validate the data (and probably
shouldn't have tried in the first place, since it likely has no reason to
have started the validation process).

> MUST ignore this SIG when deciding whether to trust the key.

Exactly.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Sep 2000 09:55:55 +0859 ()

Brian;

> have started the validation process).

It is one (among many) of a fatal design flaw I pointed out long ago
that SECDNS fails to separate the roles of resolvers and name servers.

You are seeing the result.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Sep 2000 22:19:49 -0400

>is not stored in the DNS.

This is not a "correct" question.  An arbitrary point in the DNS will be a
"preconfigured point of trust" is some reolvers and not others.  It's
always relative to the resolver's point of view.  (Trust is always in the
eye of the behold[ing resolv]er.)

The process of validation is done internal to a resolver.  The resolver
"knows" what is the relevant "universe" of pre-configurated points of trust
- as far as the resolver is concerned.

During the validation process, given a piece of data and a signature
"certifying" the data according to a particular key, the question to be
asked before doing any crypto is "do I (the resolver) *care* if the
signature validates the data?"

A rational resolver will care about the signature if (among other things)
the key used to verify the signature is trusted.  The issue being discussed
is how does the rational resolver come to determine the trustworthyness of
a key?

Acheiving the trust needs to be done in such a way that limits the exposure
to over-use of resources given dubious credentials (the clogging concern),
in such a way that limits the chance that trust can be gained through fraud
(shadowy data signers), and in such a way that legitimately trustworthy
data is maximized.

Okay, so much for the Internet Philisophical Task Force ...

IMHO - allowing one key of a set to extend trust to other members of it's
own set is a good thing.  Restricting this only to a resolver's
preconfigured keys is implementationally a reasonable restriction, but
perhaps this restriction is not necessary.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Sep 2000 12:27:31 +0200

>eye of the behold[ing resolv]er.)

This is why the configuration of the resolver cannot enter into the question
of whether it is legal or not to store a particular record in the DNS.
That is - we agree.