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
- [perpass] TLS/SSL Perfect Forward Secrecy and Key… Yakov Shafranovich
- Re: [perpass] TLS/SSL Perfect Forward Secrecy and… Patrick Pelletier
- Re: [perpass] TLS/SSL Perfect Forward Secrecy and… Stephen Farrell
- Re: [perpass] TLS/SSL Perfect Forward Secrecy and… Yakov Shafranovich
- Re: [perpass] TLS/SSL Perfect Forward Secrecy and… Stephen Farrell
- Re: [perpass] TLS/SSL Perfect Forward Secrecy and… Patrick Pelletier