Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 9 May 2006 09:41:41 -0400

Here's how I addressed these issues in http://ops.ietf.org/lists/ 
namedroppers/namedroppers.2006/msg00617.html

ISSUE 1: IPR, CLOSED
Use available replacement text
------------------------------------------------------------------
ISSUE 2: Mandatory to Implement, CLOSED
There was one comment received on this which suggested that the text  
was nonsensically phrased. Since there was no comment from anyone who  
understood the issue to suggest otherwise, no new text relative to  
"mandatory to implement" is seen as necessary.
------------------------------------------------------------------
ISSUE 3: Requirements draft has presentation flaws, CLOSED
Changes that were suggested to address issue 5 may have fixed this.  
There were no other suggestions made to correct any specific  
presentation deficiencies.
------------------------------------------------------------------
ISSUE 4: Requirements draft does not explicitly mention advertising  
key "lifetimes", CLOSED
There was concurrence that the requirements document should not deal  
with the concept of key lifetimes.
------------------------------------------------------------------
ISSUE 5: WG submission has embedded requirements in definitions, CLOSED
Use available replacement text
------------------------------------------------------------------
ISSUE 6:  draft-moreau-dnsext-tak-req-00 has other useful  
requirements, CLOSED
There was one vote against including non-degrading trust as a  
requirement. Since no one seemed to disagree with this, the action is  
to remove "non-degrading trust" as a requirement. No new requirements  
from draft-moreau-dnsext-tak-req-00 were separately identified.
------------------------------------------------------------------
ISSUE 7: New Requirements, CLOSED

* Removed the "support for graceful consolidation of islands of  
trust" requirement since this did not receive any support

* Removed the "DNS response size" requirement since this did not have  
support

* Added the "Time Delay" requirement since this had support. Mike had  
suggested the following text as replacement for the "Time Delay"  
requirement: "Protection against N-1 compromise. E.g. you can recover  
as long as at least one key is not compromised. The time-delay in my  
draft was a derivative from this - a specific mechanism rather than a  
base requirement."
I paraphrased this as:
       5.12.  Recovery From Compromise
       The Trust Anchor Rollover solution MUST allow a security
       aware resolver to be able to recover from the compromise
       of any of its configured Trust Anchors for a zone so long as
       at least one other key, which is known to have not been
       compromised, is configured as a Trust Anchor for that same
       zone at that resolver.
------------------------------------------------------------------
ISSUE 8: Wording of existing requirements, CLOSED
Action: There was no argument in favour of using 12 months as the  
reconnection interval. There was no argument in favour of retaining  
this requirement as such. So the action is to remove "support  
reconnecting systems" as a requirement.
------------------------------------------------------------------

There were two new potential requirements that were identified in the  
mailing list:

I) How often is too often/not often enough to pull/push/verify status?
    http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00575.html

    The following text (again extracted from a mail Mike sent me) may  
capture the intent of this requirement:
       5.5.  Detection of Stale Trust Anchors
       The Trust Anchor Rollover solution MUST allow a validating
       security-aware resolver to be able to detect if the DNSKEY or
       DS RR(s) being used as its Trust Anchors are no longer valid.

II)  There should be a way/method to maintain IOTs
    http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00566.html

    And here's what I added:
       5.11.  Support for Trust Anchor Maintenance Operations
       The Trust Anchor Rollover solution MUST support operations
       that allow a validating security-aware resolver to add a new
       Trust Anchor, delete an existing Trust Anchor, or replace an
       existing Trust Anchor with another.

Suresh

On Apr 7, 2006, at 11:23 AM, 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.
>
> Suresh (on behalf of the editors)
>
> --
> 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/>

--
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: Thu, 25 May 2006 15:04:23 +0200

On Apr 9, 2006, at 12:13 AM, Ben Laurie wrote:

>>
>>   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).
>
> 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.

That is not how I read the initial proposed text.

I read this proposed requirement as (paraphrased): "The method must  
provide sufficient means to ensure authenticity and integrity so that  
by the existing trust relation does not degrade by performing the  
rollover."

If that is a correct interpretation it does not rule out a federated  
solution. (Besides, if the requirements are such that they rule out a  
federated solution because another proposal matches the requirements  
better, then so be it. that is the reason we try to get the  
requirements finalized).

No hats,

--Olaf

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 25 May 2006 15:28:53 +0200

Ooops....

I seem to be reopening a closed issues only because I missed Suresh'  
excellent concluding mail on the list of issues (http://ops.ietf.org/ 
lists/namedroppers/namedroppers.2006/msg00624.html). Now I reread the  
archive and I can add that Suresh's mail actually captures the  
consensus on the list.

There were two further issues raised in that mail that were not  
further discussed. I propose that if there are no furhter comments on  
that we close the issues list and go for last call.

Note is taken of Thierry's posting. I'll reply to that note separately.

--Olaf

On May 25, 2006, at 3:04 PM, Olaf M. Kolkman wrote:

>>>    deemed sufficiently trustworthy by the operator of the  
>>> security-aware
>>>    resolver to ensure source authenticity and integrity of the  
>>> new RR(s)
>> federated solution (for example, my I-D on key seeding, which  
>> could also
> provide sufficient means to ensure authenticity and integrity so  
> that by the existing trust relation does not degrade by performing  
> the rollover."
>
> If that is a correct interpretation it does not rule out a  
> federated solution. (Besides, if the requirements are such that  
> they rule out a federated solution because another proposal matches  
> the requirements better, then so be it. that is the reason we try  
> to get the requirements finalized).
>
>
> No hats,
>
> --Olaf
>
>
>
>

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 25 May 2006 10:20:44 -0400

> archive and I can add that Suresh's mail actually captures the  

The relevant excerpt is
"There was one vote against including non-degrading trust as a 
requirement. Since no one seemed to disagree with this, the action is to 
remove "non-degrading trust" as a requirement."

Accordingly, a TAK solution that allows degrading trust over a sequence 
of rollover events is aceptable.

Sorry for repeating an argument already made, I deliberately abstain 
from contributing to the progress on 
draft-ietf-dnsext-rollover-requirements, based on the assumption that 
these discussions would be unproductive.

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]