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

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.

--
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: Thierry Moreau <[email-masked]>
Date: Mon, 27 Feb 2006 20:52:00 -0500

Dear Hilarie:

First, the conventional "Thanks for your interest in our individual
sumbission draft." applies to your message.

It is thus a pleasure for me to attempt answer the questions you asked.

> Neither document explicitly mentions advertising key lifetimes.

This is discussed in section 3.3 in the document 
draft-moreau-dnsext-tak-req-00.txt. Not an explicit formal requirement 
though.

> Is there really such a thing as an emergency rollover?

In essence, the document draft-moreau-dnsext-tak-req-00.txt circumvents
the definitional issue for "emergency rollover".

For resolvers, this is discussed in the 4th to last and 3rd to last 
paragraphs of section 2.2.

On the authoritative nameserver side, please refer to the 2nd 
requirement in section 2.3: by implication, the presence of a possible 
"breached state" (in the key life-cycle diagram) mandates support of 
emergency rollover by nameservers.

> being part of the hierarchy?

This is discussed in section 3.2. Not an explicit formal requirement though.

> Should everyone treating it as a 

The document draft-moreau-dnsext-tak-req-00.txt des not mandate this
behavior.

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]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 28 Feb 2006 09:22:52 +0100

Hilarie,

Thanks for making this inventory....

You wrote:
>  I don't think either one serves as a starting point for modification.

Personally I think a 3rd document would be overkill and a waist of  
time. We want to have a rough consensus document on which we can base  
trade-offs. Once all issues have been identified and we have a rough  
consensus on what we want we can start making tradeoffs.

I propose that the editors extract "Issues" out of this list so that  
we can discuss them one by one. It will help us to keep focus.

Can we count on the editors to do this in the cause of the week?

--Olaf

> TA remove its TA RR's from their resolvers?

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 Feb 2006 10:27:04 +0000

> 11. Analysis of how to avoid critical failure modes.

By implication, you are saying that the other clauses are not good. What
is wrong with them?

> Trust Relationship (the WG submission seems to contradict itself on

Surely a requirements document (at least an initial one) is bound to
have contradictory requirements?

I'm not sure I agree that IPR is a point of contention - there's some
detailed discussion over exactly how to best phrase the requirement to
be able to produce free software, but no disagreement over the
underlying requirement (apart from Thierry Moreau, who would like us to
use his IPR).

> Is there really such a thing as an emergency rollover?

There's certainly such a thing as a compromised key, and that's what
needs to be dealt with.

> TA remove its TA RR's from their resolvers?

It seems to me the answer is "clearly not" - some people may have a
stronger trust relationship with a zone than with its parent.

Presumably software is going to end up distinguishing between keys that
should be trusted so long as there is no signed path to them, and keys
that should be trusted whatever happens.

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

---

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

> This is discussed in section 3.2. Not an explicit formal

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.

> The document draft-moreau-dnsext-tak-req-00.txt des not mandate this

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