Re: Recall: Key rollover Work.

Gustavo Lozano <glozano@nic.mx> Thu, 06 July 2006 20:18 UTC

From: Gustavo Lozano <glozano@nic.mx>
Subject: Re: Recall: Key rollover Work.
Date: Thu, 06 Jul 2006 15:18:29 -0500
Lines: 126
References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_459026945==.ALT"
X-From: owner-namedroppers@ops.ietf.org Thu Jul 06 22:24:31 2006
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.1
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
To: Namedroppers <namedroppers@ops.ietf.org>
In-Reply-To: <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl>
References: <6.2.5.6.2.20060612102822.03b52c00@ogud.com> <7.0.1.0.2.20060612174002.03d76008@nominum.com> <2805B0B0-CFA9-49E7-8ABD-4279673564D8@NLnetLabs.nl> <6.2.5.6.2.20060626105457.050ea9a8@nic.mx> <1C71D26A-A127-42B8-948B-F2808A3AC947@NLnetLabs.nl>
X-Virus-Scanned: by amavisd-new at nic.mx
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072215.2560.40201.ARCHIVE@ietfa.amsl.com>

At 09:52 AM 6/27/2006 +0200, Olaf M. Kolkman wrote:
>Still we new more reviewers. By having people comment and choose on
>proposals we can get forward progression.

My 2 cents.

I reviewed the following key rollover drafts:

draft-laurie-dnssec-key-distribution-02.txt
draft-ietf-dnsext-trustupdate-timers-02.txt
draft-ietf-dnsext-trustupdate-threshold-01.txt

And also read:
Vixie new RR at APEX idea

draft-moreau-dnsext-takrem-dns-02.txt
Not reviewed because of 5.2 of requirements draft.

draft-laurie-dnssec-key-distribution-02.txt
Laurie's draft is a nice idea and if the WG wants to look for 
out-of-band solutions to priming keys this is a serious proposal. I 
see scalability issues if this proposal is used as the in-band 
proposal and I prefer a solution that only depends on DNS infrastructure.

Timers and threshold are, from my perspective, the best approaches to 
the problem of key rollover. I believe both drafts can be worked as 
the solution.

I like the idea of the revocation bit in timers draft but adding a 
new bit to DNSKEY will require the modification of more code. I have 
doubts about how transparent the matching of DNSKEY by the DS record 
and current implementations can work if the revocation bit is 
introduced. Threshold will need fewer queries than timers as the 
drafts are currently written and I like this from my operator's 
perspective. If one draft is to be chosen I prefer threshold because 
of the previous reasoning but I could support timers if it's chosen by the WG.

What I would want in future threshold draft versions:
    * I think that the Vixie new RR at the apex idea is interesting 
and it could be incorporated into threshold draft.
    * I would like a suggestion of M and N values so operators can 
take decisions on our DNSSEC zones.
    * Knowing if a TA was rolled because of a key compromise or a 
normal (scheduled) key rollover is important. If a TA was rolled 
because of a key compromise and I was using it as TA then I will like 
to make an initial key setup procedure. I don't know if this had been 
proposed before but we can use the hash of the key as an owner name, 
query for it and obtain status and other information about a specific 
key. This can also add a revocation feature like timers to threshold 
and revolvers could be able to know about past keys.


Gustavo Lozano
NIC Mexico