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

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.

> What happens when a zone switches from being an island of trust to
> being part of the hierarchy?

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

> Should everyone treating it as a 
> TA remove its TA RR's from their resolvers?

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]

--
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: "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

>
> 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.
>
> 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).
>
> being part of the hierarchy?  Should everyone treating it as a
> Hilarie Orman
> Purple Streak, Inc.

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

---

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

Hilarie Orman wrote:
> 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.
> 
> ---------------------
> 

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

> The WG submission hints at the issue in saying that a resolver probably

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