Subject: Re: Recall: Key rollover Work.

From: Andrew Sullivan <[email-masked]>
Date: Sat, 1 Jul 2006 09:16:40 -0400

On Fri, Jun 30, 2006 at 03:41:16PM -0400, Andrew Sullivan wrote:
> I did not review draft-weiler-dnssec-dlv-01.txt yet, because I did
> not initially think that it was a candidate to satisfy the
> requirements.  I'm happy to do so, however (is that wanted?).  I

I read this very quickly, on my commute home yesterday, and while I
cannot pretend to have a deep or complete understanding, I am pretty
sure that it does not solve any Trust Anchor rollover problems.  It
moves them, but the DLV keys still need to be rolled.  There does not
appear to be anything in the draft that will satisfy requirement
5.11, at the very least, so I don't think it's a candidate.  (It's
still likely a good draft -- I'm not prepared to speak too much to it
at present -- just not an answer to the problem the requirements
state.)

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

--
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: Ben Laurie <[email-masked]>
Date: Mon, 03 Jul 2006 10:33:26 +0100

Gustavo Lozano wrote:
> At 04:19 PM 6/28/2006 +0000, Paul Vixie wrote:
>> if we were willing to cut&paste the root zone's key (and by local
>> policy, some other set of trust anchors) into every validator, then there
>> would be no automated trust anchor project going on in this working
>> group.
> 
> Statements: I don't want to start a flame war. I am committed to review
> the keyrollover proposals and participate with my two cents.
> 
> I gave a DNSSEC workshop to a carrier in Mexico months ago. When I
> mentioned the keyrollover work being done in the IETF they asked me if
> automatic trust anchor keyrollover is really necessary to deploy
> DNSSECbis and this question has been in my head since.
> 
> Since the first time I read about DNSSECbis it became clear the
> usefulness of having a signed root. I know about the trouble of signing
> the root, but when the root is finally signed I expect that RSA is
> broken first before the root zone key is compromised. I expect that the
> entity chosen for root signing implements the same operational security
> that Verising uses to guard its root CA private key. If the root is
> signed and a root key compromise happens, it's going to be "big news"
> (think of CNN alert news) and people will update.

Note that having the root signed is only the start of the solution. You
also need an unbroken chain of signed zones from the root to every zone
that wants to deploy DNSSEC.

> 
> If the root is never signed, IANA can have a list of the trusted anchor
> currently used by each TLD and we know that communication between IANA
> and the TLDs is already authenticated. You can think of a lot of
> operational procedures to propagate this information from IANA to end
> users: windows update, RHN, cvsup, https GET by the DNS implementation,
> etc. The trick is that if you don't update your TA in your validator
> then your client's DNS request will fail and someone is going to scream
> and you will have to fix it. I expect that TLDs will implement a
> security infrastructure (here at NIC Mexico cctld .mx we are thinking
> about FIPS 140-2 level 3 HSMs for example) to protect the key so I think
> that a key rollover should be an isolated event.
> 
> Is DNSSECbis deployable without an automatic trust anchor keyrollover
> feature? Maybe what we need is a key management security guideline in
> the spirit of RFC3647 or we can add more operational security best
> practices to the existent dnssec operational practices? Maybe we are
> trying to make a perfect protocol and we just need a pretty good protocol?
> 
> Thank you for your comments.
> 
> 
> Gustavo Lozano
> NIC Mexico
> 
> -- 

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Jul 2006 14:49:34 +0000

> that wants to deploy DNSSEC.

you mean "from some trust anchor" not "from the root", surely?

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 06 Jul 2006 15:18:29 -0500

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

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 7 Jul 2006 10:08:05 -0400

My own personal "preferences" from having compared the different  
proposals are similar to what Wouter expressed in http://ops.ietf.org/ 
lists/namedroppers/namedroppers.2006/msg00869.html.

I like the revoke bit in the timers approach and I also find the  
simplicity and statelessness of resolvers in the M-of-N approach very  
appealing. Paul's optimization involves some amount of protocol  
modification, so although I see the value of his approach I also see  
its usefulness being somewhat blurred by this. TAKREM's support for  
reconnections after minor offline periods and its ability to allow  
inspection of past trust anchors is useful, but then again I don't  
see this feature out-weighing the IPR issue.

IMHO a combination of M-of-N and the revoke feature in the timers  
approach would be ideal (if this is indeed possible and the authors  
are willing to combine these). If not, I'd be in favour of the timers  
approach simply because of the revoke feature and the ability to  
signal and recover from compromise. In the latter approach, the add  
hold-down timer is useful, but as Mike says in his draft, it "mitigate 
[s] but [does] not completely solve" the problem of an attacker using  
a compromised key to add a new key. I think to keep the rollover  
component simple at the resolver, the add hold-down feature can go  
and something akin to the priming key can be used instead.

I also feel that "stale" trust anchors will likely play a more  
important part in practice than we seem to be willing to admit. My  
personal preference is to also see Ben's approach standardized as one  
way to solve the problem of initial distribution of priming keys.

Suresh

On Jun 28, 2006, at 6:12 PM, Suresh Krishnaswamy wrote:

>
> On Jun 27, 2006, at 3:52 AM, Olaf M. Kolkman wrote:
>
>>
>> Note that Alberto Martínez Herrera's comparison is still available  
>> at:
>> http://docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf
>>
>> I recall there is a second comparison but I cannot find it.
>
>
> The table at http://www.dnssec-tools.org/docs/trust-anchor- 
> comparison-v02.htm may also be useful.
>
> Suresh
> (on behalf of myself)
>
>
>
>
> --

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 8 Jul 2006 08:34:59 +0200

On Jul 7, 2006, at 4:08 PM, Suresh Krishnaswamy wrote:

> are willing to combine these).

To be precise; it is not the authors that need to be willing, it is  
the working group. Obviously we would need the authors/editors to be  
responsive to the wg needs.

Anyway, there needs to go some thinking into putting revoke into an M- 
N like approach.

Any engineer that wants to put their mind to that. Is it feasible?  
How does the state diagram look? &c, &c...

Oh, Suresh, thanks for reviewing. :-)

--Olaf

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