Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation

From: Patrick Pelletier <[email-masked]>
Date: Mon, 2 Sep 2013 23:41:40 -0700

I'd definitely like to see such a thing.  I feel like PFS in TLS is a  
bit fragmented since not everyone is ready to jump on the ECDHE  
bandwagon:

https://bugzilla.redhat.com/show_bug.cgi?id=319901

but the situation with plain old DHE is not that great, since server  
software often uses ridiculously small prime sizes, and makes it hard  
for the user to configure larger ones:

http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

and even if the server is willing to use a larger Diffie-Hellman  
prime, the problem is that clients often don't support larger primes  
either, and the server has no way to know what the client is willing  
to accept.  Older (but still in use) versions of Java, and apparently  
also Windows, only support 1024 bit Diffie-Hellman (see above  
ivanristic URL for references on these), which of course is generally  
considered too small to be secure today.  And until recently, NSS only  
supported prime sizes up to 2236 bits:

https://bugzilla.mozilla.org/show_bug.cgi?id=636802

If the server chooses a prime size larger than the client can handle,  
the handshake will fail.  I still think we need a TLS extension so  
that the client can tell the server what prime sizes it will accept  
(perhaps in the form of min/max/multiple), with the server assuming  
something conservative like 1024 (even though that is sadly  
inadequate) if the client doesn't send the extension:

http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html

But besides a TLS extension, I think what you suggest is good, some  
sort of informational RFC that would recommend "best practices" for  
PFS, e. g. something along the lines of "put ECDHE cipher suites first  
(for performance and so Java won't choke on DHE), make sure you  
support at least secp256r1 and secp384r1, put DHE cipher suites  
second, use a prime size of 2176 bits (largest multiple of 64 less  
than 2236)" or whatever.

Also perhaps some recommendations (and maybe this is what you're  
getting at with key rotation) about how (and whether) to make use of  
session resumption, and especially session tickets, when PFS is  
desired, since these can weaken it.

--Patrick

On Sep 2, 2013, at 5:37 PM, [email-masked] wrote:

> From: Yakov Shafranovich <[email-masked]>
> Date: September 2, 2013 1:02:52 PM PDT
> To: [email-masked]
> Subject: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation
>
>
> There has been some chatter about Perfect Forward Secrecy (PFS) and
> insufficient key rotation for SSL/TLS. Is this something that should
> merit discussion and perhaps an information draft with
> recommendations?
>
> Thanks,
> Yakov

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Sep 2013 10:31:46 +0100

Patrick, Yakov,

The TLS PFS stuff sounds to me like a fine internet draft.
Why don't you two go write it up as one?

Then when the -00 version is out, ask if the TLS wg want
to adopt it as a work item. If they don't want to do the
work within the wg, but don't object to it being done,
then I'd take a look at AD sponsoring it. But either way,
I'd expect that if it had reasonable content then we
should be able to turn it into an RFC without too much
pain.

As to content, it'd maybe be better to keep the BCP like
bits separate from any new TLS extension definition but
if you think they belong together just do that for the
-00 version and it can be sorted out later if need be.

Feel free to ask me off-list if you need any help with
how to go about getting that done.

And assuming Patrick and Yakov can take this on, I'm
sure they'd be interested in hearing from anyone else
who'd like to help do the work.

Cheers,
S.

PS: If this works out, it'd nicely fit what Sean and
I hoped would be the modus operandi for this list - find
a concrete thing that can be improved, (plus some
victims willing to do the work:-), get that turned into
an internet-draft, and then Sean and I can help figure out
how to fit it into some IETF WG or get it AD sponsored.
More examples are very welcome.

On 09/03/2013 07:41 AM, Patrick Pelletier wrote:
> bit fragmented since not everyone is ready to jump on the ECDHE bandwagon:
> 
> and even if the server is willing to use a larger Diffie-Hellman prime,
> the problem is that clients often don't support larger primes either,
> and the server has no way to know what the client is willing to accept. 
> Older (but still in use) versions of Java, and apparently also Windows,
> only support 1024 bit Diffie-Hellman (see above ivanristic URL for
> references on these), which of course is generally considered too small
> to be secure today.  And until recently, NSS only supported prime sizes
> up to 2236 bits:
> 
> the handshake will fail.  I still think we need a TLS extension so that
> the client can tell the server what prime sizes it will accept (perhaps
> in the form of min/max/multiple), with the server assuming something
> conservative like 1024 (even though that is sadly inadequate) if the
> client doesn't send the extension:
> 
> But besides a TLS extension, I think what you suggest is good, some sort
> of informational RFC that would recommend "best practices" for PFS, e.
> g. something along the lines of "put ECDHE cipher suites first (for
> performance and so Java won't choke on DHE), make sure you support at
> least secp256r1 and secp384r1, put DHE cipher suites second, use a prime
> size of 2176 bits (largest multiple of 64 less than 2236)" or whatever.
> 
> Also perhaps some recommendations (and maybe this is what you're getting
> at with key rotation) about how (and whether) to make use of session
> resumption, and especially session tickets, when PFS is desired, since
> these can weaken it.
> 
> --Patrick
> 
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

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

In addition to PFS, there is also a larger issue of SSL key rotation.
PFS is really a means to get to a session key that gets generated
every time. We have a separate issue with those not using PFS like
plain RSA, etc. where they key is not rotated often enough. Assuming
an attacker has access to the server's key, they can decrypt
everyone's traffic.

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?

Thanks

On Tue, Sep 3, 2013 at 2:41 AM, Patrick Pelletier
<[email-masked]> wrote:
> I'd definitely like to see such a thing.  I feel like PFS in TLS is a bit
> fragmented since not everyone is ready to jump on the ECDHE bandwagon:
>
> software often uses ridiculously small prime sizes, and makes it hard for
> the user to configure larger ones:
>
> and even if the server is willing to use a larger Diffie-Hellman prime, the
> problem is that clients often don't support larger primes either, and the
> server has no way to know what the client is willing to accept.  Older (but
> still in use) versions of Java, and apparently also Windows, only support
> 1024 bit Diffie-Hellman (see above ivanristic URL for references on these),
> which of course is generally considered too small to be secure today.  And
> until recently, NSS only supported prime sizes up to 2236 bits:
>
> If the server chooses a prime size larger than the client can handle, the
> handshake will fail.  I still think we need a TLS extension so that the
> client can tell the server what prime sizes it will accept (perhaps in the
> form of min/max/multiple), with the server assuming something conservative
> like 1024 (even though that is sadly inadequate) if the client doesn't send
> the extension:
>
> But besides a TLS extension, I think what you suggest is good, some sort of
> informational RFC that would recommend "best practices" for PFS, e. g.
> something along the lines of "put ECDHE cipher suites first (for performance
> and so Java won't choke on DHE), make sure you support at least secp256r1
> and secp384r1, put DHE cipher suites second, use a prime size of 2176 bits
> (largest multiple of 64 less than 2236)" or whatever.
>
> Also perhaps some recommendations (and maybe this is what you're getting at
> with key rotation) about how (and whether) to make use of session
> resumption, and especially session tickets, when PFS is desired, since these
> can weaken it.
>
> --Patrick
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Sep 2013 13:47:27 +0100

Hiya,

On the non-PFS topic:

> rotation with the ensuing implications for those who do not want/can

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?

There are however plenty of other good reasons for
rotating RSA keys more frequently. For the web, I guess
the wpkops wg [1] would be a good place to discuss
that, but that list has been quiet recently. And that
doesn't cover other uses of TLS either, so discussing
it here is fine for now. If we start to approach some
conclusion then we can find the right venue then.

S.

[1] http://tools.ietf.org/wg/wpkops

---

From: Patrick Pelletier <[email-masked]>
Date: Thu, 5 Sep 2013 17:54:10 -0700

On Sep 2, 2013, at 11:41 PM, Patrick Pelletier wrote:

> PFS, e. g. something along the lines of "put ECDHE cipher suites  
> first (for performance and so Java won't choke on DHE), make sure  
> you support at least secp256r1 and secp384r1, put DHE cipher suites  

Well, in light of Bruce Schneier's recommendations today, maybe DHE  
should be prioritized over ECDHE:

http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929

Although there is still the issue that DHE is slower than ECDHE.  Is  
Curve25519 the answer?

--Patrick