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
- RFC2672bis DNAME update document Ólafur Guðmundsson /DNSEXT co-chair
- RE: RFC2672bis DNAME update document Eastlake III Donald-LDE008
- Re: RFC2672bis DNAME update document David Blacka
- Re: RFC2672bis DNAME update document Mike StJohns
- Re: RFC2672bis DNAME update document Mark Andrews
- Re: RFC2672bis DNAME update document Paul Vixie
- Re: RFC2672bis DNAME update document Mark Andrews
- Key rollover work, was Re: RFC2672bis DNAME updat… Olaf M.Kolkman
- Re: Key rollover work, was Re: RFC2672bis DNAME u… Gustavo Lozano
- Recall: Key rollover Work. Olaf M. Kolkman
- Re: Recall: Key rollover Work. bmanning
- Re: Recall: Key rollover Work. Sam Weiler
- Re: Recall: Key rollover Work. Olaf M. Kolkman
- Re: Recall: Key rollover Work. Jaap Akkerhuis
- Re: Recall: Key rollover Work. Edward Lewis
- Re: Recall: Key rollover Work. Robert Story
- Re: Recall: Key rollover Work. Ben Laurie
- Re: Recall: Key rollover Work. Ben Laurie
- Re: Recall: Key rollover Work. Paul Vixie
- Re: Recall: Key rollover Work. Olaf M. Kolkman
- Re: Recall: Key rollover Work. Olaf M. Kolkman
- Re: Recall: Key rollover Work. Paul Vixie
- Re: Recall: Key rollover Work. Sam Weiler
- Re: Recall: Key rollover Work. Paul Vixie
- Re: Recall: Key rollover Work. Sam Weiler
- Re: Recall: Key rollover Work. Edward Lewis
- Re: Recall: Key rollover Work. Paul Vixie
- Re: Recall: Key rollover Work. Sam Weiler
- Re: Recall: Key rollover Work. Paul Vixie
- Re: Recall: Key rollover Work. Suresh Krishnaswamy
- Is keyrollover neccesary? (was Key rollover Work.) Gustavo Lozano
- Re: Is keyrollover neccesary? (was Key rollover W… Paul Vixie
- Re: Is keyrollover neccesary? (was Key rollover W… Thierry Moreau
- Re: Recall: Key rollover Work. Wouter Wijngaards
- Re: Is keyrollover neccesary? (was Key rollover W… Edward Lewis
- Re: Recall: Key rollover Work. Wesley Griffin
- Re: Recall: Key rollover Work. Andrew Sullivan
- Re: Recall: Key rollover Work. Thierry Moreau
- Re: Recall: Key rollover Work. Andrew Sullivan
- Re: Is keyrollover neccesary? (was Key rollover W… Ben Laurie
- Re: Is keyrollover neccesary? (was Key rollover W… Paul Vixie
- Re: Recall: Key rollover Work. Gustavo Lozano
- Re: Recall: Key rollover Work. Suresh Krishnaswamy
- Re: Recall: Key rollover Work. Olaf M. Kolkman