Subject: ISSUE 1: IPR, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:33:20 -0400

ISSUE 1: IPR

STATUS: OPEN

REFERENCE:

   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00267.html
   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00370.html

DESCRIPTION: The following change was made to section 5.2

   Old Text:
       The solution SHOULD not have any intellectual property
       encumbrance on either the technologies used by the solution
       nor implementations of the solution. The technology used by
       the solution SHOULD permit implementers to provide complete,
       running implementations that have Berkley open source type
       of licensing.

   New Text:
       Because trust anchor rollover is considered
       "mandatory-to-implement", section 8 of [RFC3979] requires
       that the technology solution chosen must be unencumbered or
       must be available under royalty-free terms.

       For this purpose, "royalty-free" is defined as follows:
       world wide, perpetual right to use, without fee, in commerce
       or otherwise, where "use" includes descriptions of algorithms,
       distribution and/or use of hardware implementations,
       distribution and/or use of software systems in source and/or
       binary form, in all DNS or DNSSEC applications including
       registry, registrar, domain name service including authority,
       recursion, caching, forwarding, stub resolver, or similar.

       In summary, no implementor, distributor, or operator of the
       technology chosen for trust anchor management shall be expected
       or required to pay any fee to any IPR holder for the right to
       implement, distribute, or operate a system which includes the
       chosen mandatory-to-implement solution.

--
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: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:36:01 -0400

ISSUE 2: Mandatory to Implement

STATUS: OPEN

REFERENCE:

msg00307.html
msg00333.html
msg00334.html

DESCRIPTION:

   For which zones is the automated trust anchor rollover mechanism
   "mandatory-to-implement"?
   Possible answers: root zone; root and "public" zones; all zones

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:37:40 -0400

ISSUE 3: Requirements draft has presentation flaws

STATUS: OPEN

REFERENCE:

msg00228.html

DESCRIPTION:

   There was some concern expressed in the mailing list that the WG
   submission contradicted itself on some places.
   In order that this document express a clear set of requirements,
   there needs to be a clear statement from the Working Group about
   what these presentation flaws are and how they may be corrected.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:39:11 -0400

ISSUE 4: Requirements draft does not explicitly mention advertising  
key "lifetimes"

STATUS: OPEN

REFERENCE:

DESCRIPTION:

   Keys don't have lifetimes; however, is this concept useful in the
   context of trust anchor rollover solutions?

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:40:44 -0400

ISSUE 5: WG submission has embedded requirements in definitions

STATUS: OPEN

REFERENCE:

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00206.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00228.html

DESCRIPTION:

   Added the following text to the "Timeliness" 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.

   Added the following text to the "Scalability" requirement:
       The automated Trust Anchor Rollover solution MUST be
       able to support Trust Anchors for multiple zones and
       multiple Trust Anchors for each DNS zone.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:42:06 -0400

ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements

STATUS: OPEN

REFERENCE:

DESCRIPTION:

   Added the following requirement:

   5.11.  Non-degrading Trust

    The method or methods used for Trust Anchor Distribution MUST be
    deemed sufficiently trustworthy by the operator of the security- 
aware
    resolver to ensure source authenticity and integrity of the new RR 
(s)
    to maintain the Initial Trust Relationship required to designate
    those RR(s) as Trust Anchor(s).

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 11:43:47 -0400

ISSUE 7: Text for new requirements

STATUS: OPEN

REFERENCE:

msg00233.html
msg00530.html
msg00539.html

DESCRIPTION:

   Added the following requirements based on inputs received:

   5.12.  Support for graceful consolidation of islands-of-trust

    The automated Trust Anchor Rollover solution MUST allow a zone to
    gracefully transition from an island-of-trust to a chain from its
    parent.

   5.13. Time Delay

     In order to limit the damage that can be caused by an attacker
     using a compromised key, the automated Trust Anchor Rollover
     solution MUST NOT allow trust anchors in security-aware
     resolvers to be replaced instantly. This feature MUST NOT prevent
     instant invalidation of trust anchors that are known to be
     non-trustworthy.

   5.14. DNS Response Size

    If the solution is implemented using the DNS, the queries
    and answers involved in the key rollover solution for a
    normal case scenario MUST fit in the upper UDP limit of
    EDNS0 (4096 bytes).

---

From: Mike StJohns <[email-masked]>
Date: Fri, 07 Apr 2006 12:07:12 -0400

Having it phrased this way makes it a nonsensical 
requirement.  Mandatory to implement is a product requirement not a 
zone requirement.

The text that goes into the standards document should be something 
like: "Any compliant resolver MUST implement the key rollover 
mechanism for trust anchors.  A compliant resolver MAY, subject to 
configuration, decline to update its trust anchors for any given 
trust point using this mechanism."

At 11:36 AM 4/7/2006, Suresh Krishnaswamy wrote:
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00307.html
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00333.html
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00334.html
>
>DESCRIPTION:
>

---

From: Mike StJohns <[email-masked]>
Date: Fri, 07 Apr 2006 12:11:25 -0400

Keys don't have lifetimes, signatures do.  Any given key in the DNS 
should last until its superceded or revoked.   Anything else would be 
a base change to the protocol (and orthogonal to the concept of key rollover)

Which in turn implies that the rollover document doesn't need 
to/shouldn't deal with this concept.

At 11:39 AM 4/7/2006, Suresh Krishnaswamy wrote:

>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html
>
>
>DESCRIPTION:
>

---

From: Mike StJohns <[email-masked]>
Date: Fri, 07 Apr 2006 12:24:53 -0400

At 11:43 AM 4/7/2006, Suresh Krishnaswamy wrote:
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00233.html
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00530.html
>   http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00539.html
>
>DESCRIPTION:
>

I'm trying to figure out if this is a valid requirement or 
moot.  Here's the deal.  If an island of trust (IOT)chains to a 
superior trust anchor, I *think* data validates if it chains either 
to the IOT trust anchor or to the superior trust anchor.  (E.g. I 
start with a nominum.com trust anchor and later add a .com trust 
anchor and stop signing stuff with my nominum.com key - I think this 
just works).

It may be better to restate this as requiring a method to delete an 
embedded trust point (e.g. all the trust anchors at nominum.com that 
were previously configured in end resolvers).

>     instant invalidation of trust anchors that are known to be

change "replaced" to "added".    We need to talk about "replacement" 
as the two separate actions "add" and "revoke" since these two 
actions will generally be separated in time.

>    normal case scenario MUST fit in the upper UDP limit of

This bothers me.  I don't think this is a requirement we can or 
should enforce. I think this translates to "DNSSEC can't use TCP" in some ways.

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Apr 2006 14:18:31 -0400

ISSUE 8: Wording in some existing requirements needs to be changed

STATUS: OPEN

REFERENCE:

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00203.html

DESCRIPTION:

Requirement 5.5 currently states that "the solution MUST support
rollover for security-aware resolvers that have been disconnected
from the network for up to twelve months."

There is disagreement over the choice of twelve months as the
disconnection period that MUST be supported.

Is there a better value? If not, is there any benefit for the resolver
to support the ability to buffer some amount of outage, and if so,
can this be stated more generically as a requirement?

---

From: Ben Laurie <[email-masked]>
Date: Sat, 08 Apr 2006 23:13:34 +0100

Suresh Krishnaswamy wrote:
>    deemed sufficiently trustworthy by the operator of the security-aware
>    resolver to ensure source authenticity and integrity of the new RR(s)

Woah! This appears to make it impossible to implement any kind of
federated solution (for example, my I-D on key seeding, which could also
be used for rollover). It would also rule out changing the authority for
the keys.

Cheers,

Ben.

-- 
http://www.links.org/

---

From: Ben Laurie <[email-masked]>
Date: Sat, 08 Apr 2006 23:15:51 +0100

Suresh Krishnaswamy wrote:
> In a short while I'll be sending out a list of pending issues (currently
> 7 in number) for draft-ietf-dnsext-rollover-requirements-00. All of
> these issues were extracted from e-mails that were sent to namedroppers
> relative to this topic over the last month.
> 
> Sample text appears in most places. If you don't agree with the wording
> in the sample text please speak up. In places where there is no sample
> text, silence will be interpreted as an implicit agreement by the
> Working Group to close this issue without further changes.
> 
> The hope is to have each of these issues resolved over the next two
> weeks so that the next version of the requirements draft can be rolled
> out and last-called in the relatively near future.

The issue that some of the definitions are actually requirements appears
to have been dropped.

Cheers,

Ben.

-- 
http://www.links.org/

---

From: [email-masked]
Date: Sun, 9 Apr 2006 16:15:06 +0000

> can this be stated more generically as a requirement?

	we are designing for 60 months.

--bill

---

From: [email-masked]
Date: Sun, 9 Apr 2006 16:14:06 +0000

> were previously configured in end resolvers).

	i'm actually concerned about network mobility...
	there may need to be a set of IOT chains that can be augmented
	with "learned" data, but i'm not sure they should be automaticially
	deleted.  but yes, there should be a way/method to maintian
	IOTs... even when the IOT is the whole tree. :)

--bill

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 10 Apr 2006 09:12:13 -0400

Issue 5 "Embedded requirements" was meant to capture this. Do you  
have suggestions for any new requirements that fall under this  
category? Feel free to send text.

Thanks!
Suresh

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Apr 2006 06:02:49 +0100

Suresh Krishnaswamy wrote:
> Issue 5 "Embedded requirements" was meant to capture this. Do you have
> suggestions for any new requirements that fall under this category? Feel
> free to send text.

Whoops, sorry. I think that looks good.

>> --http://www.links.org/

-- 
http://www.links.org/

---

From: "Hilarie Orman" <[email-masked]>
Date: Sat, 8 Apr 2006 16:46:17 -0600

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

The problem of definitions containing requirements is part of
"presentation flaws".  Other flaws include at least one unused definition,
a definition that contradicts requirements, and an unfortunate
ordering of definitions (alphabetical, which causes most definitions
to depend on other definitions appearing later in the ordering).

>  Ben.

Hilarie