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

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:
> 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
> 