Subject: RE: CGA Issue #11: Key lifetimes (Russ Housley)

From: "Tuomas Aura" <[email-masked]>
Date: Tue, 6 Apr 2004 03:53:37 -0700

Jari wrote about the changes to Section 7.1:
> I agree with the text you have provided, but what about
> brute force attacks on RSA keys? I seem to remember that
> the mandated key length is small, so perhaps with some
> time on their hands, an attacker could discover the private
> key without compromising the node. Maybe you should add
> something about not keeping the keys longer than you
> believe the keys are cryptographically safe? Or am I
> missing something obvious?

This is a valid point. However, the right reaction to 
factoring attacks is not to set a maximum lifetime for the 
keys but to increase key length. The reason is that 
increasing the key refresh rate has only a linear effect
on the security while increasing the key length has a
near-exponential effect. 

Here is a new proposal for the end of Section 7.1:

  The minimum RSA key length required for SEND is only 384 
  bits. So short keys are vulnerable to integer-factoring 
  attacks and cannot be used for strong authentication or 
  secrecy. On the other hand, the cost of factoring 384-bit 
  keys is currently high enough to prevent most denial-of-service 
  attacks. Implementations that initially use short RSA keys 
  SHOULD be prepared switch to longer keys when denial-of-service 
  attacks arising from integer factoring become a problem.

  The impact of a key compromise on CGAs depends on the 
  application for which they are used. In SEND, it is not a 
  major concern. If the private signature key is compromised 
  because the SEND node itself has been compromised, the attacker 
  does not need to spoof SEND messages from the node. When it is 
  discovered that a node has been compromised, a new signature 
  key and a new CGA SHOULD be generated. On the other hand, if 
  the RSA key is compromised because integer-factoring attacks 
  for the chosen key length have become practical, the key needs 
  to be replaced with a longer one, as explained above. In either 
  case, the address change effectively revokes the old public 
  key. It is not necessary to have any additional key revocation 
  mechanism or to limit the lifetimes of the signature keys. 

I would also add the following sentence to the cautionary
notes in Section 7.4 Related Protocols:

  Second, the minimum RSA key length of 384 bits may be too 
  short for many applications and the impact of key compromise 
  on the particular protocol needs to be evaluated. 

Tuomas

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: 31 March 2004 19:40
> To: Tuomas Aura
> Cc: SEND WG
> Subject: Re: CGA Issue #11: Key lifetimes (Russ Housley)
> 
> Tuomas,
> 
> I agree with the text you have provided, but what about
> brute force attacks on RSA keys? I seem to remember that
> the mandated key length is small, so perhaps with some
> time on their hands, an attacker could discover the private
> key without compromising the node. Maybe you should add
> something about not keeping the keys longer than you
> believe the keys are cryptographically safe? Or am I
> missing something obvious?
> 
> --Jari
> 
> Tuomas Aura wrote:
> > Russ Housley:
> >
> >   The security considerations ought to say something about the
lifetime
> >   of the public/private key pair.  The one brief statement in
section
> > 7.3
> >   is not sufficient for an implementor to know how often the key
pair
> >   needs to be changed.
> >
> > ---
> >
> > Tuomas Aura:
> >
> > There isn't any reason for changing the keys, except if the
> > host is compromised and its private keys may have leaked.
> >
> > I suggest adding the following to Section 7.1:
> >
> >   The impact of key compromise depends on the
> >   application of the CGA-based signatures. In SEND, it is not a
> >   major concern. The private signature key is typically stored
> >   in the physical node that uses the CGA generated from the
> >   corresponding public key. If the private key is compromised, it
> >   is likely that the node itself has been compromised. If that is
> >   the case, the attacker does not need to spoof SEND messages
> >   from the node. When it is discovered that a node has
> >   been compromised, a new signature key and a new CGA SHOULD be
> >   generated. The address change effectively revokes the
> >   old public key. It is not necessary to have any additional
> >   key revocation mechanism or to limit the lifetimes of the
> >   signature keys.
> 
> 

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 6 Apr 2004 09:10:19 -0700

Yes, this sounds fine.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Apr 2004 20:29:41 +0300

>   on the particular protocol needs to be evaluated. 

Ok. Thanks.

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Apr 2004 12:34:49 +0300

>   on the particular protocol needs to be evaluated.

Looks good.

--Pekka