Subject: [perpass] TLS/SSL Key Rotation

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 3 Sep 2013 19:18:49 -0400

[splitting threads]

On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell
<[email-masked]> wrote:
> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote:
>> The CA/browser forum has begun some steps in this direction by
>> lowering validity of SSL server certificates to 18 months. Is there a
>> place for a discussion on recommending a lower time period for key
>> rotation with the ensuing implications for those who do not want/can
>> not use PFS?
>
> This list is a fine place for discussing that if you
> think that a shorter RSA key rollover duty cycle would
> impact on pervasive monitoring. I'm not clear as to
> how it would though. Have you some scenario in mind?
>

The scenario would be where the RSA key on the server is compromised
or forcefully disclosed via a court order or other legal mechanism.
The shorter the interval, the less data would be available to the
potential attacker. There has been media discussion about this with
the US Government [1] where providers are forced to hand over their
keys.

I would also point out that TLS/SSL is used in non web scenarios as
well. In cases of provider to provider SMTP, XMPP, SIP, etc.
connections, there is a lot more data that can be sucked up if the key
is compromised. Unlike web browsers, where there are some mechanisms
in place to warn the user, SMTP, XMPP, SIP, etc. connections on a
provider to provider level would be automated and no user may see the
warnings until after the fact.

Yakov

[1] http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-for-master-encryption-keys/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Sep 2013 00:43:32 +0100

Hiya,

> The scenario would be where the RSA key on the server is compromised

Potential private key leakage is a fine reason to more frequently
roll key pairs. But I'm not so sure that's related to the topic
of this list. You have to assume that the compromise is because of
some non-repeatable event for it to be relevant here I think.
I'm not sure that that's really so likely, but willing to be
educated otherwise.

I'd guess its really more likely that a private key compromise
that's relevant here would involve persistent exploit code running
that can constantly grab the latest private key and I can't see
that anyone can roll keys so often as to achieve near the same
effect as PFS for such a case.

> the US Government [1] where providers are forced to hand over their

Right, but if the TLAs come calling, and the service provider's
response is to hand over today's RSA private key and then roll a
new keypair then you'll have an unhappy TLA, who'll come right
back calling again. The phone records thing (court order being
renewed every 3 months or whatever it was) also seems to argue
that rolling key pairs isn't going to help really.

> warnings until after the fact.

Fully agree. But I'm still not seeing how its related to the
topic of this list really.

S.

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 3 Sep 2013 20:11:38 -0400

>>> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote:
...
> that rolling key pairs isn't going to help really.

One could envision a scenario where a small group of users or a
particular user is being targeted by the court order for a limited
period of time. Having regular key rotation will not stop the TLAs
from reading everyone's email but will limit the damage once the key
rotates.

Yakov

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Sep 2013 03:55:09 +0000

> the US Government [1] where providers are forced to hand over their

I agree with Stephen that key rollover would never be frequent enough to provide meaningful FS. It's also likely that a country where court orders for RSA keys get issued will also have laws requiring companies to retain old private keys for a certain period of time, just as there are laws requiring the retention of certain documents and correspondence.

Is seems to me that using ciphersuites with PFS, whether ECDHE or DHE, would be a better way. Google is not implementing it at scale on their servers. All browsers support some ECDHE ciphersuites, and they're also supported in libraries such as OpenSSL. So PFS is just a configuration away. Easier than manually or automatically rotating certificates often, no?

Yoav

---

From: Patrick Pelletier <[email-masked]>
Date: Wed, 04 Sep 2013 12:33:43 -0700

> I agree with Stephen that key rollover would never be frequent enough to provide meaningful FS. It's also likely that a country where court orders for RSA keys get issued will also have laws requir…

With the current CA business model, probably not.  But in theory, if 
things were changed so that keys could be rotated every month, every 
day, or potentially every hour, then that could provide meaningful FS.

I'm not aware of any laws in the US that require old keys to be kept. So 
if the NSA came knocking, they could compel you to turn over current 
(and possibly future) keys, but if one had already erased one's previous 
keys, that would keep prior communication safe.

Also, legal means are not the only way a state actor (or non-state 
actor) could acquire a private key.  They could use zero-day exploits to 
break into a computer in another country (or, depending on their 
morality, in their own country) and obtain the private key.  Frequent 
key rotation would ensure that any communication that had happened prior 
to the break-in would be safe.

> Is seems to me that using ciphersuites with PFS, whether ECDHE or DHE, would be a better way. Google is not implementing it at scale on their servers. All browsers support some ECDHE ciphersuites,…

Yes, I do think PFS ciphersuites are a better way.  Although sometimes 
I've heard "performance" given as a reason for not enabling PFS.  In 
that case, frequent key rotation (if the CAs cooperate) would allow much 
of the benefit of PFS, at essentially no additional computational cost.

--Patrick

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Sep 2013 07:21:09 +0900

> that case, frequent key rotation (if the CAs cooperate) would allow
> much of the benefit of PFS, at essentially no additional computational
> cost.

the operational cost, and room for mistakes, should not be discounted.

randy