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

Patrick Pelletier <code@funwithsoftware.org> Tue, 03 September 2013 06:41 UTC

Return-Path: <code@funwithsoftware.org>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8452111E8193 for <perpass@ietfa.amsl.com>; Mon, 2 Sep 2013 23:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HyFlpoJy2p7 for <perpass@ietfa.amsl.com>; Mon, 2 Sep 2013 23:41:51 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5011E818E for <perpass@ietf.org>; Mon, 2 Sep 2013 23:41:50 -0700 (PDT)
Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.39]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id E7BB81EE511F for <perpass@ietf.org>; Tue, 3 Sep 2013 02:41:45 -0400 (EDT)
Received: (qmail 14766 invoked from network); 3 Sep 2013 06:41:45 -0000
Received: by simscan 1.4.0 ppid: 31326, pid: 7148, t: 2.0903s scanners: clamav: m:
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender <code@funwithsoftware.org>) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for <perpass@ietf.org>; 3 Sep 2013 06:41:43 -0000
Message-Id: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org>
From: Patrick Pelletier <code@funwithsoftware.org>
To: perpass@ietf.org
In-Reply-To: <mailman.904.1378168674.3384.perpass@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail-12-451342203"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 02 Sep 2013 23:41:40 -0700
References: <mailman.904.1378168674.3384.perpass@ietf.org>
X-Mailer: Apple Mail (2.936)
Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2013 06:41:56 -0000

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