Subject: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt

From: [email-masked]
Date: Tue, 21 Feb 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Requirements related to DNSSEC Trust Anchor Rollover

	Author(s)	: S. Crocker, et al.
	Filename	: draft-ietf-dnsext-rollover-requirements-00.txt
	Pages		: 
	Date		: 2006-2-21
	
   Every DNS security-aware resolver must have at least one Trust
   Anchor to use as the basis for validating responses from DNS signed
   zones. For various reasons, most DNS security-aware resolvers are
   expected to have several Trust Anchors. For some operations, manual
   monitoring and updating of Trust Anchors may be feasible but many
   operations will require automated methods for updating Trust Anchors
   in their security-aware resolvers. This document identifies the
   requirements that must be met by an automated DNS Trust Anchor
   rollover solution for security-aware DNS resolvers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rollover-requirements-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-ietf-dnsext-rollover-requirements-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-ietf-dnsext-rollover-requirements-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.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 26 Feb 2006 14:42:19 +0000

Russ Mundy wrote:
> see in-line:
> 
> On 2/23/06 at 7:16 PM -0000, Ben Laurie <[email-masked]> wrote: 
>> [email-masked] wrote:
>> Comments:
>> Emergency Trust Anchor Rollover:
>>
>>  "Any security-aware resolver
>>   using those RR(s) as Trust Anchor(s) must quickly remove them from
>>   use by the resolver."
>>
>> Surely not - what must happen is they must start using the new keys
>> and stop using the old ones.
> 
> The current wording may need improved but I think that your suggested change
> infers that there _will_ (or MUST) be new keys available at the time that the

implies, surely. But in any case if there aren't new keys it isn't rollover.

> 'old' keys should no longer be used, e.g., 'old' keys have been compromised.
> While I agree that having new keys in place when old keys are removed is the
> most desireable state but I believe that there is a real possibility that a
> zone may not have new keys available so that the zone can no longer be
> operated as signed.  In that case, the security-aware resolver should stop
> using the old key as a TA and treat everything under that hierarchy as _not_
> signed.  In other words, the TA should no longer be used even though a new key
> is not available.  Do you have some wording suggestions?

I really would prefer that the definition of rollover and the
requirements were separated.

Here's what I'd suggest:

Emergency Trust Anchor Rollover

   The operator of a signed zone has issued new DNSKEY RR(s) and/or DS
   RR(s) as part of an exceptional event.

Emergency Trust Anchor Revocation

   The operator of a signed zone wishes to indicate that the current
   DNSKEY and/or DS RR(s) are no longer valid as part of an exceptional
   event.

with the requirements moved down to the requirements section.

>> Normal or Scheduled Trust Anchor Rollover:
>>
>>  "Operators of security-aware resolvers using RR(s) from that zone as
>>   Trust Anchors need to acquire new and remove revoked Trust Anchors
>>   at roughly the same time as the signed zone issues or revokes
>>   RR(s)."
>>
>> Actually the requirement is that they don't use revoked ones after
>> they are revoked and do use new ones. Why is this different? Because
>> it allows resolvers that are offline for an extended period to comply.
> 
> I agree that this definition doesn't mesh particularly well with 5.5 but I
> don't think that they conflict either in that when a system is 'returning from
> offline' there should be an effective, secure method for it the resolver to
> use only valid TAs.  Do you have some suggested words here?

Again, split the definition from the requirement, and make the requirement:

Operators of security-aware resolvers using RR(s) from that zone as
Trust Anchors need to acquire new and remove revoked Trust Anchors such
that no old key is used for long after revocation."

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
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: "Hilarie Orman" <[email-masked]>
Date: Mon, 27 Feb 2006 12:27:53 -0700

Both requirments documents have good points and severe flaws in
presentation.  I don't think either one serves as a starting point for
modification.

Here's my attempt to summarize the requirements from each --- I've
tried to preserve the inconsistencies and confusions, possibly
introducing new ones:

Individual Submission (Moreau)

1. Entity named in whois information for the zone must
   adopt documented procedures and protocols.
2. Resolver must have trusted configuration store.
3. Resolver may initialize trust at first instantiation of zone keys.
4. Support automated rollover to greatest possible extent.
5. Trustworthiness must be >= previous trustworthiness.
6. Rollover method must have analysis (disclosure) of catastropic
   failure modes.
7. Resolver must be able to detect key revocation, and
   resolver must be able to detect key re-use.
8. Management scheme must have analysis of dependency on
   initial out-of-band distribution of trusted information.
9. Must support two keys at once (incoming and retiring keys).
10. Resolver must be able to detect key revocation.
11. Analysis of how to avoid critical failure modes.

-----------------------

Working Group Submission

1. Scalability for Internet-wide usage.
2. No IPR; Berkeley open source licensing recommended.
3,4. Applicable to root zone and all others, including private networks.
5. Reconnection after 12 months should be OK.
6. Manual or automated.
7. Scheduled and non-scheduled rollover.
   a. Initial Trust Relationship is optional.
8. Timely distribution of TA RRs.
9. Trustworthy distribution of new RRs and retraction of outdated RRs.
10. New RR types are a question to the WG.

  Requirements derived from the definitions:
1. Resolvers must switch to using new RRs quickly in an emergency rollover.
2. Resolvers must obtain TA RRs in a trustworthy manner.
3. Zone operator issues new keys and optionally revokes old keys;
   resolvers must switch to using the new keys at "roughly" the same time.
4. Resolvers may have any number of TAs for any number of zones.
5. Resolver operators are responsible for using a trustworthy method
   of obtaining TAs.  The integrity and authenticity must be
   assured.  No TA can be used unless there is an Initial Trust Relationship.
6. Issuer of TA RRs and users of same must know exactly which RRs are
   revoked.

---------------------

The WG submission's main 1, 3, 4, 8, and 9 look good.  The WG
submission's reqs from definitions 1, 2, and 5 are also good.
Moreau's 5, 7 (second clause), and 9 look like good things that aren't
in the other draft.

Neither document explicitly mentions advertising key lifetimes.
The WG submission hints at the issue in saying that a resolver probably
won't use more than 20 TA's.  Does this mean 20 manually configured
lifetimes and ad hoc methods (telephone call?) of update notification?

The IPR issue seems to be a point of contention, as is the Initial
Trust Relationship (the WG submission seems to contradict itself on
this point).

Is there really such a thing as an emergency rollover?

What happens when a zone switches from being an island of trust to
being part of the hierarchy?  Should everyone treating it as a 
TA remove its TA RR's from their resolvers?

Hilarie Orman
Purple Streak, Inc.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 28 Feb 2006 08:30:02 -0500

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Thierry Moreau

> > being part of the hierarchy?
>
> This is discussed in section 3.2. Not an explicit formal
> requirement though.
>

Perhaps it should be (in whatever final requirements draft is produced).  Or
at least the requirement that a zone transitioning from an island of trust
to a chain do so gracefully.  Especially in the first years of DNSSEC
rollout, as more zones move from being islands to part of a chain.

"Gracefully" would also mean that a zone continues to publish its own trust
anchor in addition to having it as part of a chain.

> > Should everyone treating it as a
> The document draft-moreau-dnsext-tak-req-00.txt des not mandate this
> behavior.
>

Either the validator would remove the TA, or continue to validate/update it
when possible through the chain.  This would be a policy decision if it was
believed the zone would move from chained back to an island for some reason.

Scott

> Best regards,
>
> --
>
> - Thierry Moreau
>
> CONNOTECH Experts-conseils inc.
> 9130 Place de Montgolfier
> Montreal, Qc
> Canada   H2M 2A1
>
> Tel.: (514)385-5691
> Fax:  (514)385-5900
>
> web site: http://www.connotech.com
> e-mail: [email-masked]
>
>
>
> --