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

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
<code@funwithsoftware.org> 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:
>
> 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, perpass-request@ietf.org wrote:
>
> From: Yakov Shafranovich <yakov-ietf@shaftek.org>
> Date: September 2, 2013 1:02:52 PM PDT
> To: perpass@ietf.org
> 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
>
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>