Subject: Re: Continuing the work on key-rollover

From: Andrew Newton <[email-masked]>
Date: Tue, 04 Apr 2006 16:41:31 -0400

Olaf M. Kolkman wrote:
> No other issues have been brought up. If you have any other issues or 
> requirements then please speak up next week[*]. The editors promised to 
> stay on top of the document (by volunteering Suresh for the job, thanks!).
[..snip..]
> [*] Somebody told me that they would like to see the ability to add  a 
> 'time-delay' as a property of the rollover scheme. To paraphrase: That 
> way one cannot compromise the system and immediately run with it. A 
> mala-fide roller will have to sit on the compromised system for a while 
> before it can be abused. (I can't recall who mentioned this but if 
> somebody supports this requirement, please speak up).

While I wasn't the one who mentioned it to you (don't know who it was), 
this sounds like a good idea. A key compromise MUST NOT allow attackers 
to replace trust anchors instantly.

-andy

--
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: Gustavo Lozano <[email-masked]>
Date: Wed, 05 Apr 2006 17:19:36 -0500

I think that the following requirement is obvious 
but just in case I am sending it to the list.

Requirement:
If the solution uses the DNS as transport then 
the queries and answers involved in a normal case 
scenario MUST fit in a 4096 bytes UDP packet.

Why? Because, I don't want resolvers opening TCP connections to my servers.

At 09:56 AM 3/30/2006 +0200, Olaf M. Kolkman wrote:

>Dear Colleagues,
>
>After Re-issuing issue 1 [1] and asking for a hum at the physical
>meeting I plan to close the issue next week and ask the editors to
>add the text.
>
>requirements then please speak up next week[*]. The editors promised
>to stay on top of the document (by volunteering Suresh for the job,
>thanks!).
>
>I hope that Suresh can whip up a new revision in a week or two and if
>there are no further comments we'll last call it.
>
>In the mean time, please look at the various proposals on the table.
>The document that Alberto Martínez Herrera 
>provided to us in November [2] might, or even 
>will, be useful. (URL: http:// 
>docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf).  There
>are other people that did comparison matrices, can they please
>provide links?
>
>If there are folk that have any other rollover-proposals to add then
>please submit that seem to fit to the requirements; better start
>writing text but please do realize that you add entropy :-) .
>
>I hope we can converge to one spec before next IETF.
>
>
>--Olaf
>
>[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00370.html
>[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01546.html
>
>[*] Somebody told me that they would like to see the ability to add
>a 'time-delay' as a property of the rollover scheme. To paraphrase:
>That way one cannot compromise the system and immediately run with
>it. A mala-fide roller will have to sit on the compromised system for
>a while before it can be abused. (I can't recall who mentioned this
>but if somebody supports this requirement, please speak up).
>
>
>-----------------------------------------------------------
>Olaf M. Kolkman
>NLnet Labs
>http://www.nlnetlabs.nl/
>
>
>
>
>

gus

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 6 Apr 2006 14:46:16 +0200

On Mar 30, 2006, at 9:56 AM, Olaf M. Kolkman wrote:

>  The document that Alberto Martínez Herrera provided to us in  
> November[2] might, or even will, be useful. (URL: http:// 
> docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf).

Some people have had issues with opening this document.

Alberto just explained to me:
> I have been trying to use any browsers to check the document. There  
> is a
> strange behaviour on IE. It does not allow to check the document  
> when the
> adobe plug-in is used. However when the document is downloaded to  
> the PC
> there is not any trouble to read it using Adobe 6.0/7.0 . With  
> Mozilla (all
> versions) and Opera there is not any trouble to check the document.  
> I'm going
> to investigate the origin of the trouble when IE is used and solve  
> it soon.
>

I guess that explains things a bit and provides you alternatives to  
open the document.

--Olaf

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 6 Apr 2006 09:52:38 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Andrew Newton
>
> Olaf M. Kolkman wrote:

I agree with this requirement for scheduled rollovers, I don't feel certain
it should apply for emergency rollovers.  Mainly the issue in replacing a
compromised key.  I would like to see the vulnerability period of a
compromised key be as small as possible.

Scott

---

From: [email-masked]
Date: Thu, 6 Apr 2006 17:08:14 +0000

> I guess that explains things a bit and provides you alternatives to  

	well... safari has problems (just the first page is downloaded)
	and mozilla/firefox downloads something that gives a 110 error.
	using adobe 6.0.2 pro.  ... on a Mac-G4.

---

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

>but if somebody supports this requirement, please speak up).

Might have been me... this was one of the things I considered in my 
draft.  I'd probably restate this as "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.