Subject: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?

From: "Dr. Pala" <[email-masked]>
Date: Thu, 30 Mar 2017 12:26:17 -0500

Hi all,

I have a small question about the I-D. In particular, it seems to me 
that this proposal circumvents any limitation on the effective lifetime 
of a short-lived-cert's keypair. From a cryptographic standpoint of 
view, it is good practice to impose strict lifetimes on keys (i.e., 
usually via validity periods in certificates) to limit the issue of 
successful attacks on the crypto scheme (e.g., key factorization). This 
proposal would de-facto remove this property by adopting re-issuing 
instead of re-keying when renewing a certificate.

Although the CA might be able to track the usage of a key from the 
initial CSRs, the automatic issuance of the certificate itself without 
the constraints of the key longevity seems quite dangerous and possibly 
open to a policy of "set-and-forget" that might last for... years... 
(automatically not re-issuing the certificate based on key-size + CSR 
timestamp would, I think, create issues for CDNs as there would be no 
indication when a new LURK/CSR cycle is needed).

Am I reading it wrong / missing something ?

Cheers,
Max

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 30 Mar 2017 12:53:34 -0500

I don't think it's the CA's job to dictate policy in this area.

-Ekr

On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala <[email-masked]> wrote:

> Hi all,
>
> I have a small question about the I-D. In particular, it seems to me that
> this proposal circumvents any limitation on the effective lifetime of a
> short-lived-cert's keypair. From a cryptographic standpoint of view, it is
> good practice to impose strict lifetimes on keys (i.e., usually via
> validity periods in certificates) to limit the issue of successful attacks
> on the crypto scheme (e.g., key factorization). This proposal would
> de-facto remove this property by adopting re-issuing instead of re-keying
> when renewing a certificate.
>
> Although the CA might be able to track the usage of a key from the initial
> CSRs, the automatic issuance of the certificate itself without the
> constraints of the key longevity seems quite dangerous and possibly open to
> a policy of "set-and-forget" that might last for... years... (automatically
> not re-issuing the certificate based on key-size + CSR timestamp would, I
> think, create issues for CDNs as there would be no indication when a new
> LURK/CSR cycle is needed).
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Max <[email-masked]>
Date: Thu, 30 Mar 2017 13:00:18 -0500

Hi Eric,

I am not saying it is the CA job (although, good CAs will impose max 
life-times on keys), but it seems to me that this issue should be 
addressed since it would violate one of the basic security principles 
when it comes to crypto, i.e. key lifetime. Maybe adding something to 
this regard could be useful so that "TLS operators" and CDN operators do 
not shoot themselves in the foot :D

Cheers,
Max

On 3/30/17 12:53 PM, Eric Rescorla wrote:
> On Thu, Mar 30, 2017 at 12:26 PM, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     I have a small question about the I-D. In particular, it seems to
>     me that this proposal circumvents any limitation on the effective
>     lifetime of a short-lived-cert's keypair. From a cryptographic
>     standpoint of view, it is good practice to impose strict lifetimes
>     on keys (i.e., usually via validity periods in certificates) to
>     limit the issue of successful attacks on the crypto scheme (e.g.,
>     key factorization). This proposal would de-facto remove this
>     property by adopting re-issuing instead of re-keying when renewing
>     a certificate.
>
>     initial CSRs, the automatic issuance of the certificate itself
>     without the constraints of the key longevity seems quite dangerous
>     and possibly open to a policy of "set-and-forget" that might last
>     for... years... (automatically not re-issuing the certificate
>     based on key-size + CSR timestamp would, I think, create issues
>     for CDNs as there would be no indication when a new LURK/CSR cycle
>     is needed).
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>
>
>
>

-- 
Massimiliano Pala
Director at OpenCA Labs
twitter: @_mpala_

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Mar 2017 22:06:34 +0300

On Thu, Mar 30, 2017 at 12:26:17PM -0500, Dr. Pala wrote:
> good practice to impose strict lifetimes on keys (i.e., usually via validity
> periods in certificates) to limit the issue of successful attacks on the
> crypto scheme (e.g., key factorization). This proposal would de-facto remove
> this property by adopting re-issuing instead of re-keying when renewing a
> certificate.

I do not think that limiting key lifetime is necressarily a good idea.

Usually, when you discover that your key is compromised (using the
WebPKI definition), the attackers have been in position to compromise
your keys for who knows how long. If you rotated keys, all (or at least
a long list) the past keys are considered compromised too.

The threat of using stolen keypairs to decrypt sessions is exactly
what PFS is meant to defend against.

There's also key rollovers for parameter updates, but those are quite
rare, and are not emergency rollovers. There are already parameters
where the time that happens is either: 1) Major cryptographical break-
through, or 2) Large quantum computers are invented.

So, I don't think CA should do anything with key lifetimes (outside
obvious indications that key is not good, like revocation with
KeyCompromise).

-Ilari

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 30 Mar 2017 15:36:30 -0500

Hi Ilari, all,

I strongly disagree with your statement. From a crypto standpoint, key 
rotation IS an important point and should be addressed. I think 
something could/should be added to the I-D to limit the number of 
renewal or the period where the same CSR can be used for certificate 
re-issuing.

The solution might be as simple as set a validity in the CSR that is 
generated (if you want that to be in control of the requesting client). 
I am not suggesting the specifics of how to solve it, but I think that 
this is a point that should be addressed (possibly something that was in 
the mind of the original authors, but did not make it in the document... 
?).

What is the position of the I-D authors ?

Just my 2 cents, of course :D

Cheers,
Max

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 31 Mar 2017 09:07:14 +0300

On Thu, Mar 30, 2017 at 03:36:30PM -0500, Dr. Pala wrote:
> rotation IS an important point and should be addressed. I think something
> could/should be added to the I-D to limit the number of renewal or the
> period where the same CSR can be used for certificate re-issuing.
> 
> generated (if you want that to be in control of the requesting client). I am
> not suggesting the specifics of how to solve it, but I think that this is a
> point that should be addressed (possibly something that was in the mind of
> the original authors, but did not make it in the document... ?).

I just read the draft. A facility to limit the private key period, 
assuming you want to do that, already exists.

And there are a number of sane-looking metrics[1], where any timed key
rotation strictly[2] decreases security.

[1] Basically, anything that considers security issue duration.

[2] Meaning you get '<' operator in comparision, not '<='.

-Ilari