Subject: Remarks on the DNS Security Extension Clarification on Zone Status draft

From: Roy Arends <[email-masked]>
Date: Thu, 11 May 2000 10:52:19 +0200 (CEST)

Comments by Roy Arends and Ted Lindgreen from NLnet Labs on the
Internet-Draft:

    DNS Security Extension Clarification on Zone Status
    <draft-ietf-dnsext-zone-status-01.txt>
    April 13, 2000, by Edward Lewis.

We start with our conclusions:
- A clarifying document is very worthwile, but we would like to suggest
not to use the terms "Fully Secured" and "Privately Secured"
- It would be good to have a Best Current Practice document to guide
DNS-administrators on implementing DNSSEC.
- The proposed updates to RFC 2535 all seem either unnecessary or
undesirable.

Mr. Lewis introduces terms and definitions of security levels: "Fully
Secured", "Privately Secured", and "Unsecured". We feel that this is very
confusing as a zone is either "Secured" or "Unsecured". Also confusing is
the interaction between parent and child zones that enter the picture.
There is no relation between this interaction and the level of security.
We would therefore prefer that these confusing terms and definitions would
not be used.
Note, the signing of a zone KEY is an interaction which is outside the
scope of this draft (as mentioned in the Introduction). Therefore we
view the terms and definitions for "On-tree Validation" and
"Off-tree Validation", which itself are very useful, as outside the
scope of this Draft. We suggest to define these terms in a BCP for
DNS-administrators on implementing the DNS Security Extensions.

Also much confusion stems from the statement in the introduction of the
Draft, that "a delegating zone is required to indicate whether a child
zone is secured".
In general this is not true, as the zone itself is responsible for its
security. There is one and only one special and temporal case when a
parent must indicate that a child is unsecure:
 when a parent zone converts from unsecure to secure, while its childs
 have no KEY (or NULL-KEY) yet.

It could be recommended in a BCP for DNS-administrators, that childs of
zones that convert to be secure are expected to either convert also or
update their own zone file with a NULL-KEY as soon as possible.

Proposed terms and definitions.

Assuming correct configurations only, we would like to define:
  A zone is "Secured" then and only then if the resolver expects a zone
    KEY for this zone and finds it to be a non-NULL KEY.
  A zone is "Unsecured" if no zone KEY is expected or a NULL-KEY is found.

These "Secured" and "Unsecured" definitions can be viewed from the
perspective from the two parties involved to clarify what must be done:

The zone administrator that wants his zone to be "Secured"
- needs to generate a zone KEY, and have this KEY signed or advertized in
  such a way that the resolvers of interest expect it and can verify it;
- inserts NULL-KEY's at delegation points for child zones that have not
  yet their own KEY (or NULL-KEY) as a temporal measure to prevent them
  from dangling.
- takes care of properly signing the zone (which includes the addition of
  NXT RRs).

The resolver that is security minded about certain parts of the DNS tree
- must be configured to know which parts of the DNS tree it expects to be
  Secured;
- must be able to walk a verification path from the zone KEY to one of its
  known and trusted KEYs;
- must be able to verify the SIGs of the relevant RRs in the zone with the
  zone KEY.

Please note that we make no mention of any special way of signing, nor
about the path of verification. Also note that there is no mentioning of
parent-child interaction, except for the temporal need to take care of not
yet converted or updated children during the conversion from "Unsecured"
to "Secured".

We read from RFC 2535 that it supports a general mechanisme of
verification, and also describes a specific possible implementation: along
the reverse of the delegation path. We view it as very important that the
general mechanisme is fully retained.

Also note that we make no mention about the algorithms that are used. It
is up to the zone administrator and with the producers of the resolvers of
interest to choose the most suitible algorithms.

We suggest that a Best Current Practice document is produced to recommend
on parent-child and KEY holder-signer communication issues and on which
algorithms to use.

Proposed updates to RFC 2535.

In 2.a of the Draft is a proposal to update RFC 2535-3.1.3 on the
requirement of the protocol field. We don't see the need for this update
as RFC 2535 is already clear on this matter (see detail number 3 in RFC
2535-3.1.3).

In 2.1.c is a proposal to update RFC 2535-2.3.2 on the requirement to use
NXT RRs. On reading RFC 2535 carefully it is clear that this requirement
is already there (see RFC 2535-5.3) and is also already implicated by the
signing process itself. Therefore, if their remains any doubt about this,
a clarification should suffice.

In 2.1.d is a proposal to update RFC 2535-2.3.1 on signing each RR, and
using a Mandatory to Implement algorithm. The former part of this
requirement is already in RFC 2535 (see 2.3.1, 2.3.4, and 3.1.1).  So this
part of the update is unnecessary. The latter part of this proposed, new
requirement severly restricts the DNS Security Extension by disallowing
other algorithm than DSA, including the Recommended to Implement
algorithms (as RSA). This part of the proposed update is undesirable.
In 2.2.d the first part of the same proposal is repeated, which is
again an update that is unnecessary.

In 3.1 a "Child Has Keys" bit is introduced which updates at least RFC
2535-2.3.4.  In contrast to the proposed name of this bit, it appears on
careful reading, that this proposed bit signals that "The Parent Has
Signed The KEY Of This Child". This is very different from its name, and
it defeats the possibility of any other verification mechanisme than the
special case along the reverse of the delegation path.  So this is a major
update of the DNS Security Extension.  We feel that the disavantage of the
limitation of the original general verification mechanisme significantly
outweights the advantage of having a somewhat smaller parent zone for some
time after the conversion from Unsecured to Secured.  We therefore
conclude that this update is undesirable.

In 5 is a proposal to update RFC 2535-3.4 on the experimental status. The
need for this update disappears when the functionality of the NULL-KEY is
retained.

Regards, 

Roy Arends,
NLnet Labs

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 May 2000 09:30:32 -0400

>Comments by Roy Arends and Ted Lindgreen from NLnet Labs on the

Thanks - I already need to rewrite this based on comments from developers.

>not to use the terms "Fully Secured" and "Privately Secured"

Partly addressing comments later on, there is a distinction to be made
amongst "secured" zones.  The rationale is that a zone's security is
dependent on factors decided by the zone admin and by factors beyond the
control of the zone admin (i.e., the parent, grandparent, etc., zone
admins).  So the three stages are unsecured, secured as best as can be, and
recognizably secure.  These correspond to local admins doing nothing, local
admins taking steps but not remote admins, and all admins taking steps.
(Paraphrasing...)

>DNS-administrators on implementing DNSSEC.

Before such a document is ripe to be written, we need to have BINDv9 out, a
couple of workshops to iron out the parent-child interaction and resolver
interpretation issues.

>- The proposed updates to RFC 2535 all seem either unnecessary or

We'd have to look at that on a case-by-case basis.

>We would therefore prefer that these confusing terms and definitions would

The interaction between parent and child is very important in determining
the child's percieved security level.  E.g., I could take evey step in
securing tislabs.com, but if com is not secured, tislabs.com won't be
secured (according to my definition of "normal" security).

>DNS-administrators on implementing the DNS Security Extensions.

What I meant was that how the "signing is done" is outside the scope of
this document.  (Perhaps I need to reword that section.)  Understanding the
difference between on-tree and off-tree are important.

Perhaps there is some more history to this document than has come out in
writing.  I have been approached by a number of folks who have proposed
using off-tree signing for validation.  E.g., governmental agencies often
contract to firms to run the operations of government centers.  One such
contractor asked me if he could sign the government's zone with his
contractor key - a mismatch of names.  My reply was to get permission to
generate a key pair himself but name it as being owned by the government.
If he didn't, no one else would know he was authorized to sign the data.
If he did, resolvers would trust by default his signatures.

> have no KEY (or NULL-KEY) yet.

A parent MUST indicate whether a child is secure or not, for some
definition of secure.

Assume a resolver gets an unsigned A record for a piece of data that should
be signed.  The resolver only knows that no SIG has arrived, so it needs to
set out to determine if there should have been a SIG.

Starting from some already known-to-be-secure (grand)parent of the target
zone, the resolver has to decend to see if the secure chain is maintained.
Once the chain is broken, all zones below are considered unsecured, whether
or not they are signed.  Note that this assume on-tree validation.  During
this search down through zones, it is possible to ask either the upper half
of a delegation whether the next step is secure or ask the lower half of
the delegation whether it is secure.

If we rely on asking the zone directly (the lower half), we are open to
zone-jacking attacks.  An unsecured zone could be replaced by a maliciously
signed zone.  Either this would result in a denial of acceptance of data as
the signatures wouldn't be accepted (no chain of trust), or, if off-tree
validation is improperly allowed, the zone-jacked data may be accepted over
the true data.

A converse attack is also possible.  If the true zone is secured and claims
itself to be, a zone-jacker could put up an unsigned, unsecured
replacement.  In this case, the malicious zone would not have the problem
of trying generate signatures.

This is why a delegating zone must indicate (implicitly or explicitly)
whether it's delegee is secure.  Now, if off-tree validation is allowed,
this very hard to do, which is why I bothered to include on-tree validation
as a prerequisite for now.  (I do have a research vehicle on the horizon to
address off-tree validation issues.)

>    KEY for this zone and finds it to be a non-NULL KEY.

But, how does a resolver know to "expect" a zone key?  The answer I have in
mind is through the proposed key-bit, or by implicit returns from the
parent zone.

>  such a way that the resolvers of interest expect it and can verify it;

What you are saying here is true, but defining "such a way that...expect"
is not so easy.  This is where this draft sits in the problem space.

I am trying to clarify what "such a way" means - and finding that for a
single admin to do this, s/he must rely on others to cooperate.  Whether
they cooperate or not is the dividing line that drives my two kinds of
security.

>general mechanisme is fully retained.

The problem with the general mechanism is that it is open to far too many
vulernabilities.

I agree that the generality is desired, but I see this as part of an
evolutionary process.  In the early stages of DNSSEC (or any secure
system), you can choose to be tight and loosen rules as time goes on, or do
the reverse, start loose and tighten as time goes on.

I am choosing to push a tight start and research ways into loosening the
rules.  The main reason is tied to software revisions.  If older revisions
are looser than new ones, then folks who don't upgrade may be open to some
attacks.  Also, attackers could use the looser software to create problems.

By starting with tight rules and loosening them in later releases, we
accomplish a few things.  One is that we have more time to understand 1)
what desired loosness truely exists, and 2) the impact of the looser rules.
Also, we now have a means to encourage folks to upgrade. (Instead of
upgrade of you risk problems, it's upgrade and you better stuff.)

>interest to choose the most suitible algorithms.

This is a bit of a different issue.  I don't want to push any algorithm.
However, in the workshops, there has been a point of confusion when we mix
folks who use just one of the two currently available algortihms.

I want to stress that this is an issue amongst "mandatory to implement"
algorithms and algorithms that are not.  This isn't an RSA vs. DSA issue,
or an issue of whether some secret agency wants to use a "superior" digital
signature technology.

>as RFC 2535 is already clear on this matter (see detail number 3 in RFC

The (albeit few) implementers I spoke too don't agree that the wording if
the RFC is a good idea.  Just about all code I've come across, mine and
others, checks that value anyway.  As far as the RFC, it takes a half-dozen
lines to describe what should be said in one line.

>a clarification should suffice.

That's what this update is about.  There are far too many times a "careful"
reading is required to understand the finer points of the standard.
(Section 5.3 is "Additional Complexity Due to Wildcards" which isn't the
place I'd stick in a "must use NXTs.")

>again an update that is unnecessary.

There is misinterpretation going on here.  This "must" only applies to
being fully secured, as opposed to being partly secured (or whatever words
are now in use).  Note that in 2.2 this isn't a requirement.

>conclude that this update is undesirable.

This is the section that will be revised to say "the bit is one if the
parent says the child is secure, zero otherwise."  This change is based on
a conversation with BIND developers (who *still* owe me emailed comments).

As far as restricting other verification meachanisms, I think I already
addressed that.

>need for this update disappears when the functionality of the NULL-KEY is

We are trying hard to drop the NULL key.  The main reason is that it is now
required for indicating a zone below is unsecured, the impact is that it is
another record a parent has to sign.  By removing the NULL key, we remove a
SIG from the parent.

Although this is crucial to just a few zones, e.g., .com, adoption by these
zone are crucial to the use of DNSSEC.

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 May 2000 14:49:56 -0400

At 9:46 AM -0400 5/19/00, Roy Arends wrote:
>Comments by Roy Arends and Ted Lindgreen from NLnet Labs

When I came to work today, I was planning on updating the draft.  When I
went search for your previous message, this arrived in my in-box.  What
timing!

There's a lot of substance in here.  I'll try to address some of it now and
leave more when I can better express some of my thoughts.

>1. You see the result of the implementation of secured DNS as a
>   completely secured tree, starting at the root.

For the sake of interoperability, I hope so.  If you publish data in such a
way that is seen as secure to only a subset of the users, then you are
probably going to be seen as unsecured to the rest.  Hence, the zone is
spoofable to the rest.

Granted, what the rest of the world sees of your zone may not be important.
There's a counter example which I'll put into another message - the example
was related to me last fall during a workshop.

>   Part of the DNS tree, perhaps including the root, may not be
>   secured at all for quite some time.

I agree with this.  Your statements on secure roots, secure trees that drop
into unsecured trees, and not back, are right on.  I did some work on this
a few years ago and noticed this.

I didn't reflect this in the draft because, well, it's a lot of work to
fully explain.

>2. You introduce levels of security. We think that a zone is either
>   secure or not and nothing in between. Perhaps this is caused by
>   an approach to the zone from the eyes of the zone administrator
>   who wants to secure his zone as good as possible but is limited
>   by his span of control. We approach it from a resolver point of
>   view with staticly configured KEYS for defined secure entry-points
>   into the DNS tree.

Yes.  Maybe this is a way to visualize what's going on:

       Server                     Resolver
(zone1)     Secure<---------->Secure
(zone2)     Secure<---------->UnSecure   (something happened external to zone)
(zone3)     Unsecure<-------->Unsecure

Zone1 is fully secure, both the server and resolver see it as secure.
Zone2 is partly secure, the server has signed the zone but the resolver
can't validate it.  Zone 3 is just unsecure.

In the draft, I am not creating levels of security within the protocol.  I
am trying to identify the Zone 2 situation to alert zone admins that
certain actions will make an otherwise secure zone seem unsecure.

The draft is merely trying to label a potential problems spot.

>3. You state that "a parent MUST indicate whether a child is secure
>   or not". We have studied this matter in detail, and read all the
>   communications on this we could find, including the comments from
>   Donald Eastlake (author of RFC 2535) on the previous version of
>   this Draft. Our conclusion is that this statement is incorrect.
>   We explain below.

I am not sure how to answer this.  When I say that "a parent MUST
indicate," the indication may be implicit.  RFC 2535 implicitly indicates a
secure child.  RFC 2535 conveys "if the parent is secure, assume the child
is too, unless you see a NULL key."

I would prefer that implicit notification of security not be used, this is
a feeling shared by some.  However, what RFC 2535 says meets the need, so
justifying a change is not reasonable.

Do you still disagree with the "MUST" above?

>4. You state that off-tree validation opens the possibility to
>   "zone-jacking" attacks. The opening you have described does not
>   exits when RFC 2535 is properly applied.
>   However, attacks are possible in both cases, but may be more
>   severe in the on-tree than in the off-tree case.

This could take a long time to explain.

One problem is that the policy in RFC section 6 is not generally accepted,
and didn't achieve consensus of the WG when the document went to the IESG a
few years ago.  I recall a promise that section 6 was to be removed,
obviously it wasn't.

You are right that the zone-jacking example wouldn't succeed if the policy
there is applied correctly.  I picked a bad example, one that was based on
another version of the policy that was discussed a while back.  I need to
refresh my memory more often.

The problems with the written ("recommended") policy include this:

The first clause usurps the delegation of the child zone by the parent.  In
other words, although .example might delegate army.example, .example has
the right to sign www.subdept.army.example.  What if subdept.army.example's
delegation is suspended by army.example?   The signed data still exists.

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 May 2000 15:46:59 +0200 (CEST)

Comments by Roy Arends and Ted Lindgreen 

Dear Mr. Lewis,

Thank you for your response on our comments.

There appears to be a difference in view on 4 subjects:

1. You see the result of the implementation of secured DNS as a
   completely secured tree, starting at the root.
   We expect that the result will be several secured subtrees,
   with different types or strenght of encryption.  Different
   resolvers may see different parts of the DNStree as secured.
   Part of the DNS tree, perhaps including the root, may not be
   secured at all for quite some time.

Before we go into detail first some background to clarify NLnet
Labs position.

- NLnet Labs is working in a Working Group of CENTR to implement DNSSEC
  in ccTLDs. We aim to have it implemented in Sweden before 1/1/2001, and
  in Germany and The Netherlands in Q1 of 2001, and we expect other ccTLDs
  to join in during this timeframe.

- Tests to secure the .se, .de, and .nl zones, using the current BIND9
  prerelease have been completed succesfully.

- We are currently setting up secured shadow versions of the three ccTLDs
  mentioned above. With these tests we intend to gain hands-on experience
  with the practical side of parent-child and KEYholder-KEYsigner
  communications and scaling problems.

- The results of our test will be compiled into document which we plan to
  shape such that it can be used as a BCP document for zone-administrators.

Because we view the proposed standard RFC 2535 as well thought-out,
and fully usable as it is now, we think that this RFC is ready to
get the status of draft standard. For that reason, we think that
only updates to this standard should be carried out, for which
there is a strong need.

Now for a detailed discussion:

ad 1.
 We do not expect that DNSSEC can or will be implemented in a fully
 top-down manner, starting at the root, quickly enough to satify the
 current demand for DNS security.
 Another reason why off-tree validation is necessary, is that
 certain sub-zones require stronger KEYs than their parents provide.
 Also KEYholder-KEYsigner relations crossing national or legal
 borders may not be suitable for some puposes.
 Finally, there are childs that need to be in control over their
 own security, and are not in control of their parent zones.
 Fortunately RFC 2535 allows off-tree validation of any zone in
 the global DNS tree.

ad 2.
 Let us look at DNSSEC from the security aware resolvers point of view.
 Security starts with one or more defined secure entry-points in the
 DNS tree, perhaps the root when DNSSEC is fully implemented, or any
 other points down. For these entry-points the resolver has one or
 more staticly configured KEYs to verify the zone-KEY it expects.

 Now, suppose the resolver-user wants to lookup a certain RR that
 belongs to some domainname. First thing to do is to check whether
 the domainname or an upper part of it is known to be Secured. If
 more parts match, it uses the longest match.

 ad 2.1. Case: not in the list of Secured entry-points.
	 Now the resolver falls back to unsecure DNS.

 ad 2.2. Case: Secured entry-point is found.
	 Now, the resolver will lookup and verify the zone-KEY and
	 enters the DNS tree in secure mode at this entry-point.
	 The resolver descends the tree towards the requested RR,
	 validating KEYs and finally the RR on its way.

	 On doing so, it may face certain complications, let's
	 check two of them.

    ad 2.2.1 Some zone KEY in between is not signed by its secure
             parent. This is a new entry-point, the resolver does
	     not know about.
	     The resolver must declare this zone as BAD, and the
	     resolver-user may want to check for updates of his
	     resolver.

    ad 2.2.2 On decending, the resolver encounters a NULL-KEY. This
	     means that the secure part of the tree has ended, and
	     the resolver falls back to unsecure DNS.

 Please note that we have made some implicit statements on the way:
 - before doing the first lookup query, the resolver already
   knows whether to expect security or not.
 - having started in the unsecure manner, it can never get secure.
 - having started in the secure manner, it can only get into the
   unsecure state when traversing a delegation with a NULL-KEY.
 - after going from secure via a NULL-KEY to unsecure, it can never
   get secure again.

ad 3.
 With every delegation from a Secured parent, there must be a zone
 KEY for the child. This follows directly and unambiguously from
 RFC 2535.
 There are 3 likely possibilities:
 1. The KEY is signed by the parent and the child-zone holds it.
    This is the usual case.  The KEY can be a zone-signing KEY
    or a NULL-KEY.
    Note that the parent says nothing about the childs security.
 2. The KEY is third party signed and is hold by the child.
    This defines a Secured-entry point, which must be preconfigured
    in the resolvers of interest for this branche of the DNS tree.
    Note that the parent says nothing about the childs security.
 3. The KEY is signed by the parent and is hold by the parent.
    This is undesirable, especially for large zones (like TLDs),
    but necessary when the child is clueless or in the transitional
    state of implementing DNSSEC. The KEY is then a NULL-KEY.
    Note that the parents says
     "watch out, this child is clueless, so security ends here".

 There are other possibilities, but these are all unlikely and/or
 undesirable.

ad 4.
 First let's look at the security hole you have described.
 You state that asking whether a zone is secure or not must
 not be done at the lower half of the delegation.
 We disagree on this.
 
 Perhaps you meant to say that we must not rely on the lower
 half on the question whether a zone has a KEY or not.
 Yes, we agree that this is absolutely essential.

 There are four possibilities:
 1. The resolver is configured to know the zone is secured
    (and has a KEY to check it).
    This zone is "off-tree" signed.
 else
 2. The parent is Secured and has no NULL-KEY for the child.
    Then this child must have a KEY, and that KEY must be
    signed by the parent (otherwise we have to declare the
    zone BAD). This zone is "on-tree" signed.
 else
 3. The parent is Secured and the parent or the child
    holds a NULL-KEY. This zone is "Unsecured".
 else
 4. The parent is Unsecured. The child is also Unsecured.

 Note, whenever we leave a Secured area of the DNS tree and we
 happen to find a KEY or SIG we can never rely on it and we
 better ignore it. RFC 2535 is specific about this. Failing
 to do so opens your security hole, but following RFC 2535
 makes this hole to disappear.

 More on zone-jacking. Note that the childs NS records are not
 signed in the parents zone file.  Zone jacking and other malicious
 attacks are possible by spoofing illegal delegation NS RR's into
 the DNS system.  Security aware resolvers will spot the attack in
 secure zones, but may face DoS, other resolvers will simply get
 fooled with wrong information.

 For better understanding let's work out the various situations
 to see what is needed and how difficult it is to pin-point a
 party we can blame and sue for damage afterwards.
 Assume a security aware resolver is used.

 ad. 4.1.
     Secured zone, with the KEY off-tree signed by a KEY which
     public part is made available and is preconfigured in the
     resolvers of interest.
     Now, to hi-jack the zone and make it undetectable, the private
     KEY of the signing party needs to be stolen or cracked, or
     someone at the signing party needs to fooled or corrupted to
     sign the hi-jackers KEY.  Pin-pointing the responsible party
     is straightforward: the signing party (who may or may not be
     able to point to the hi-jackers in turn). Claiming damage will
     depend on the signing party, and likely economic rules will
     apply for third party signers (value for money). It may also
     be expected that some very security minded zone-holders will
     take the signing of their zones in their own hands.
 ad. 4.2.
     Secured zone, delegated and signed by Secured parent.
     This involves that the parents KEY is stolen or cracked,
     or that the parents zone administrator has been fooled
     or corrupted to sign the jackers KEY.
     So this depends on the parents organisation and the
     strenght of the KEY they use.
     Pin-pointing the responsible party is straightforward
     (the parent), but claiming damage may be difficult,
     because of disclaimers, or legal and national borders.
     One can expect that large zones, as TLDs, will not be
     so keen to delegate cheaply when high claims can be
     faced, so one may expect either disclaimers or huge
     delegation costs, or that these zones simply do not
     implement DNSSEC at all.
 ad. 4.3.
     Unsecured zone delegated by Secured parent.
     This is easy, and the responsible party is difficult to
     point out. It makes little difference whether the NULL-KEY
     is hold by parent or child (in the latter case, the jacker
     just copies NULL-KEY and SIG from the real child).
 ad. 4 4. Unsecured zone delegated by Unsecured parent.
     This is just as easy to do as 4.3.

 Note, after a on-tree signed child has converted from Unsecured
 to Secured, this child is vulnerable to zone-jacking as long as
 the old NULL-KEY is still valid. Therefore, NULL-KEYs must have
 a reasonable short SIG expiration time. But this is something
 for the Best Current Practice document.

Regards,

Roy Arends,
Ted Lindgreen,
NLnet Labs.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 May 2000 13:58:12 -0400

(I appologize that this is still one and a bit rambling.)

Here are some thoughts I have driving the draft and the resultant
discussion.  I bring this up because in many places I agree with the
premises presented but disagree with the conclusions.

The original problem I had in mind when I began writing this draft was the
protection of, e.g., "www.army.example."  Assume that the army is
contracting out its DNS operations to "contractor.xy."

The desire of the army would be to have www.army.example's A records signed
by contractor.xy.  One reason for this is to stop spoofing the address of
the army website.  The army would then configure all of it's resolvers to
trust the keys of contractor.xy, hence all the army folks would trust the
unspoofed address.

However, this gives a false sense of security.  Although the army's
resolvers will now not fall to address spoofs, the true audience, those it
hopes to recruit (assuming the US version of non-drafted army) would not
trust the real address and would be open to believing a spoofed address.

There isn't a mechanism for army.example to express to the general audience
that contractor.xy is the desired signatory authority for the data.  This
missing mechanism is something I've tried to address before and without
success.

The original intent of the draft was to convey some definitions that could
be used in a later document on how to set up secure zones.  The levels of
security I define here are not intended to be meaningful to the protocol,
but put names to the classification of whether the zone is secured in the
general view, or secured in the view of just a few, or not secured at all.

Falling back to the example, had the army arranged for the contractor to
sign the zone using the army's domain name, i.e., the name which a resolver
would expect to see signing the zone barring configuration, then you would
have www.army.example signed by army.example.  This would be a "completely"
or "fully" secured zone.

With the example as stated, the zone may be safely secured and recognized
by the army resolvers, but the zone would not be seen as secured by the
general population of resolvers.  This is the situation in which the zone
is said to be "privately" or "partially" secured.

I am making the distinction on paper so that administrators can see the
impact of so-called non-standard signing algorithms and authenticators.

There is also the latent issue that the policy in section 6 of RFC 2535 is
not one that I am happy with.  Further, at the time the DNSSEC WG pushed
this document into the IESG, there was no consensus on that section and I
was promised that it would be removed.

1) The definition of DNSSEC protects resolvers, not servers.

>   completely secured tree, starting at the root.

For the sake of interoperability, I hope that eventually this is the case.

>   resolvers may see different parts of the DNStree as secured.

Is this acceptable?  As in the example above, my zone may seem secure to
all of my resolvers, but not to other resolvers.

>   secured at all for quite some time.

I agree with this and have already written software that looked at the DNS
tree as being comprised of mini trusted trees, rooted at pre-configured
trusted points and "ending" where unsecured children existed.

>   view with staticly configured KEYS for defined secure entry-points

You are right.  I am trying to document the situation from the point of
view of the server administrator.

>only updates to this standard should be carried out, for which

I think that this opinion is counter to that of some implementers.  This
dissatisfaction with RFC 2535 by implementers is what has been driving
recent drafts such as the one we are talking about now.

I really want to avoid a section-by-section analysis of RFC 2535 in this
message.

> Fortunately RFC 2535 allows off-tree validation of any zone in

I think the problem with off-tree validation is that there is no way a zone
can safely convey who are valid signers of its data.  Let's say that
validator.example is a respected signer of data and have their keys
distributed with resolvers everywhere.  If I, as a zone owner, do not want
validator.example to sign my data, I won't be able to do so.

I realize the off-tree validation is important.  In the draft I choose not
to deal with it as I see it needing more refinement.  I am not against
this, I just think we need to understand how this can be done securely.

> Let us look at DNSSEC from the security aware resolvers point of view.

That would be a discussion for a different draft.  Mine is trying to write
from the server's point of view.

As far as the rest of this section, this is approximately the algorithm I
implmented in my secured resolver (non-released, antiquated, code).

>     "watch out, this child is clueless, so security ends here".

This is why the proposal to use a bit in the NXT is made; to avoid the
parent from holding NULL keys.

> Yes, we agree that this is absolutely essential.

I'm not sure how to respond to this.  There are two questions, "is zone A
secure" and "does zone A have KEYs?"  The questions are related, differ
slightly, but both are best answered by the parent (until we figure a
secure way to go off-tree).

if zone A is secure ==> zone A has KEYs
if zone A is unsecured ==> zone A has no KEYs OR zone A has KEYs w/o zone KEY
if zone A has no KEYs ==> zone A is unsecured
if zone A has KEYs and a zone KEY ==> zone A is secured
if zone A has Keys but no zone KEY ==> zone A is unsecured

My draft now asks "does zone A have KEYS".  After a conversation with
implmenters, I am going to rewrite the draft to ask "is zone A secure"
because of issues with the validator routines.

>    This zone is "off-tree" signed.

I had not considered pre-configured to be off-tree, but intrinsically
trusted.  I always thought of off-tree as only pertaining to data signed by
keys obtained elsewhere, ultimately coming back to a trusted point.

> fooled with wrong information.

What my secured resolver did was, at a secured parent:
 1) get the keys for the child (if present)
 2) get the NS for the child
 3) get the glue for the child
and then trying the NS set of the child
 1) get the NS for the child
 2) get the KEY for the child (if needed)
 3) verify the NS from the child and make sure this was used instead of the
    set from #2 above.
 and so on.

> Assume a security aware resolver is used.

This raised a point that has been bothering me all weekend.

If we assume that DNS servers are reasonably well intentioned, then we can
be fairly loose in our policies.  If we are willing to just be able to
"blame and sue" we can also use loose policies.

I have been working from a point of view that is "paranoid" and "real
time."  I don't place trust in other servers, so I seek restrictive
policies.  I also try to prevent the use of bad data (e.g., my verification
of the "hint NS" as I decend the tree).

Another factor, besides my bias, is that tighter policies make the software
easier to write.  Releasing software that allows looser policies is more
palatable to me than having to patch old software because it used a policy
that is too loose.

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 23 May 2000 07:04:23 -0700

Roy,

Your proposed solution to allow off-tree signing seemd wonderful but created 
the mother of all key distribution problems. How does oen get the keys in, how 
does one change them... In particular, in you analysis of attacks, you missed 
the one that the attacker first persuades the resolver to configure in the 
wrong key, then does as he will. Given the explicit ability to have multiple 
keys (something needed in the normal case), it only takes getting an extra key 
on the system to destroy security. If you punt the problem and allow an 
external security system to handle the keys, then you have fundamentally 
changes the definition of the problem.

Having been in some of the discussions about what is really required to handle 
the root key, this is very very hard. You can increase the strength of the 
security of the zone key as much as you like, but until the entire delivery 
chain including the configuration of the public key onto the system at hand is 
addresses, the security is limited.

Also, I am assuming that you were using the resolver point of view in a 
didactic form. It has been the general belief that most of the work for secure 
DNS would happen on the local recursive nameservers, and use 
tsig/other/nothing to pass the response back to the resolver. Given your 
expansion of the key delivery problem, you would have to be strongly in favor 
of this. Doing the security at the local nameserver is also the only way to 
secure DNS without waiting for the installed base of local resolvers to be 
changed out (maybe 5-10 years.)

jerry

---

From: John Gilmore <[email-masked]>
Date: Mon, 29 May 2000 11:16:19 -0700

> by contractor.xy.  ...
> that contractor.xy is the desired signatory authority for the data.

Yes there is.  Give contractor.xy the private key to army.example, and
let them use it to sign www.army.example.

This is how you express trust -- by sharing your privates.  :-)

	John

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 May 2000 09:23:42 -0400

>let them use it to sign www.army.example.

Yeah, that's the solution I suggested when I first heard the situation.

In other words, bend reality into the DNS world and then follow the
restrictive rules.  I can live with that, but here's the rub.  Having
company A sign the data for companies B, C, D, etc. is one thing, having
company A hold the private keys for B, C, D, etc., sounds like key escrow.