Subject: Fwd: I-D ACTION:draft-stjohns-dnssec-trustupdate-00.txt

From: Michael StJohns <[email-masked]>
Date: Wed, 12 May 2004 10:56:48 -0400

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

FYI.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Automated Updates of DNSSEC Trust Anchors
>         Author(s)       : M. StJohns
>         Filename        : draft-stjohns-dnssec-trustupdate-00.txt
>         Pages           : 13
>         Date            : 2004-5-11
>
>This document describes a means for automated, authenticated and
>    authorized updating of DNSSEC "trust anchors".  The method provides
>    protection against single key compromise of a key in the trust point
>    key set.  Based on the trust established by the presence of a current
>    anchor, other anchors may be added at the same place in the
>    hierarchy, and, ultimately, supplant the existing anchor.
>
>    This mechanism, if adopted, will require changes to resolver
>    management behavior (but not resolver resolution behavior), and the
>    addition of a single flag bit to the DNSKEY record.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of the 
>message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-stjohns-dnssec-trustupdate-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-stjohns-dnssec-trustupdate-00.txt>

--
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: Gilles Guette <[email-masked]>
Date: Fri, 14 May 2004 09:57:37 +0200

Hello,
in your draft you say that when a key has the REVOKED bit sets, this key 
MUST NOT be use as a trust anchor except validating the RRSIG for 
revocation. And revocation is immediate.

In the section 2.2 you say that "The resolver MUST NOT treat a new key 
as a trust anchor until the hold-down time expires AND it has retrieved 
the..."

So consider the following scenario:

A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked 
the old one.

The zone owner sets the revoked bit on SEP1.
Your resolver revoked immediatly SEP1 but must not use SEP2 as trust 
anchor. At this time your resolver has not trust anchor anymore for this 
zone.

Did I miss something?

In the last paragraph of section 2.2, you say that "an attacker who 
holds one compromised key could keep a single resolver from realizing 
that a key had been compromised by intercepting real data..."

But when you compromise a key, you can generate "cryptographically 
valid" data and pollute caching servers with it. Then there is no need 
to intercept real trafic. But maybe it is out of scope here.

In section 2.4.3 you say that a resolver MUST be able to manage at least 
five SEP per trust point. Is there a particular reason for this ?
I am not sure that many zones have more than two or three SEP.

Regards

Michael StJohns wrote:
>   spam, it is easy to miss and therefore delete relevant posts   by 
> non-subsrcibers. Please fix your subscription addresses. ]
> 
> FYI.
> 
> 
> 
--
Gilles Guette
ARMOR team
IRISA/INRIA Rennes
France

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 14 May 2004 08:32:21 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gilles Guette

I believe both the SEP1 and SEP2 keys are supposed to be active for a time.
The overlap allows resolvers (validators) to learn and validate the new SEP
key before installing it as a trust anchor.  That is the impression I got.

I have some comments of my own:

meta comment - The DNSSECbis docs have seperated the "resolver" and
"validator" roles.  Adding some complexity to avoid confusion :)  The
resolver would learn of the new SEP key, but the validator would be the one
that would rollover the trust anchor.

Section 2.4.2
"This ensures that at least two DNSKEY RRSets MUST be seen by the
resolver..."  2 RRsets?  Isn't it one set, with some keys having different
flags set?

Section 5.1
Should the zone signing key be set at generation time as well?  Or is there
a specific time that is set?  Is there a time when the REVOKE bit is set and
the ZSK is cleared (and RRSIGs removed)?

Section 6.1
"...decision whether to accept a replacement trust anchor key based on trust
for a current trust anchor key..."  Sounds confusing, but don't know how to
rephrase to make it sound more clear.

second para:
Why only manual updates?  Could that include some automatic method out of
band for DNS?

I think this is a good draft for consideration on key rollover.  It does
require allocation of a new bit in the DNSKEY flag field, but that is easy
since there is plenty of room.

Scott

---

From: Gilles Guette <[email-masked]>
Date: Fri, 14 May 2004 15:30:35 +0200

> key before installing it as a trust anchor.  That is the impression I got.

In this case, I think that this model is not suitable for zone files 
having only one SEP, because if a zone has one SEP and want to change 
it, the owner of the zone must first create a new SEP and wait 30 days 
and after revoke the old SEP.

In the same way if a zone has 2 SEP (SEP1 and SEP2) and want to change 
one. The zone owner revoked SEP1 and create SEP3, it is OK but during 
the next 30 days this zone can not change SEP2 because of the same problem.

--

---

From: Mike StJohns <[email-masked]>
Date: Fri, 14 May 2004 10:51:57 -0400

At 03:57 AM 5/14/2004, Gilles Guette wrote:
>In the section 2.2 you say that "The resolver MUST NOT treat a new key as 
>a trust anchor until the hold-down time expires AND it has retrieved the..."
>
>
>A zone with one SEP (SEP1) decides to add a new SEP (SEP2) and revoked the 
>old one.
>
>anchor. At this time your resolver has not trust anchor anymore for this zone.
>
>Did I miss something?

Nope.  You've just wiped out the trust anchors for the zone.  That's why 
the recommendation is for one active, one stand by key.

>In the last paragraph of section 2.2, you say that "an attacker who holds 
>one compromised key could keep a single resolver from realizing that a key 
>had been compromised by intercepting real data..."
>
>But when you compromise a key, you can generate "cryptographically valid" 
>data and pollute caching servers with it. Then there is no need to 
>intercept real trafic. But maybe it is out of scope here.

I think I understand what you're saying.  My assumption is that the data in 
the zone can normally get to the resolvers, but a determined attacker who 
has managed to compromise a trust anchor key can block and replace traffic 
headed for only a small set of resolvers (obviously this assumes the 
attacker hasn't ALSO broken into the zone servers).  The design of this 
mechanism is such that the attacker would need to do this for EVERY 
transaction during the hold-down time (30 days) to permanently corrupt the 
one specific server.  The moment the resolver sees the revoked key all of 
that cryptographically valid data goes away.

>I am not sure that many zones have more than two or three SEP.

There needed to be some minimum, this one seemed to be reasonable.  There 
needs to be at least three - (revoked, active, standby), having 5 gives you 
some leeway.

---

From: Mike StJohns <[email-masked]>
Date: Fri, 14 May 2004 11:39:23 -0400

At 04:20 AM 5/14/2004, Gilles Guette wrote:
>I think another point should be explain in the draft (maybe only few lines):
>
>If a zone changes its trusted anchor and your resolver does not querried 
>this zone during the change. After the change, your resolver is unable to 
>validate a new trusted anchor and the change must be made manually.

Not exactly. Assume two anchors, an active anchor A and a standby anchor 
B.  Assume you're doing a normal rollover (e.g. out with the old, in with 
the new).  At time T you do (A, B, C) sign(A,B).  At time T+30 days you do 
(REVOKE(A),B,C)sign(A,B), at time T+60 or more days you do 
(B,C)sign(B).  At time T+1year its time to rollover B.  As long as the 
resolver has queried the zone at least once during the year its been able 
to install C as a standby anchor.   That actual worry is that you don't 
query the zone during the time the REVOKE(A) is present and leave A around 
as an anchor.

For zones like the root, it shouldn't be a problem - if you don't query the 
root in a month you may have other problems.  For zones like 
wildostriches.com it will be more of a problem.  OTOH - if you really need 
wildostriches.com validated you're probably connecting to them fairly often.

I'll expand the security consideration section to cover more of this 
discussion.

Thanks - Mike

It is possible for a zone owner to totally and completely screw up the 
trust anchors, but its also as possible for him/her to screw up the signatures.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 14 May 2004 11:06:02 -0400

>that would rollover the trust anchor.

I think that's implementation detail.  The validator can still get data 
from the resolver.  Is there something specific that should be said?

>resolver..."  2 RRsets?  Isn't it one set, with some keys having different

Hmm... badly worded.  What I meant was that the resolver has to see the new 
DNSKEY in the RRSet twice - and at least one of those had to be after the 
expiration of the TTL in which the DNSKEY first appeared.  E.g. the 
resolver has to fetch the DNSKEY RRSet at least twice at different times 
from the zone servers.

>the ZSK is cleared (and RRSIGs removed)?

My reading of the documents may be confused, but I thought the ZSK was 
necessary to validate a signature, but there's no requirement that there be 
associated signatures for any key  In any event if the ZSK needs to be set 
for the SEP bit to be set then I can note that here.

>rephrase to make it sound more clear.

I'll look at it again.

>Why only manual updates?  Could that include some automatic method out of

Let me change "manual" to "out of band" to correct this.

>since there is plenty of room.

Thanks.  And thanks for the excellent on-the-point comments.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Fri, 14 May 2004 11:06:02 -0400

I'll look at it again.

Mike