Re: [TLS] DHE key derivation

Yoav Nir <ynir@checkpoint.com> Fri, 27 September 2013 21:25 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6311E80DE for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 14:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.378
X-Spam-Level:
X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 K86sIwKLCH8c for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 14:24:56 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3FCC21E8053 for <tls@ietf.org>; Fri, 27 Sep 2013 14:24:51 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8RLOjE8014286; Sat, 28 Sep 2013 00:24:45 +0300
X-CheckPoint: {5245F79D-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Sat, 28 Sep 2013 00:24:45 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [TLS] DHE key derivation
Thread-Index: AQHOu5NbQv44CSd39EaD4bVemn9dSJnZm1OAgABEWwCAAAbYAA==
Date: Fri, 27 Sep 2013 21:24:44 +0000
Message-ID: <66004AFF-3120-4887-9591-094404792ED6@checkpoint.com>
References: <CAMm+Lwioy8Z+wo7czrOT+5-HOf-G=8X3MF-bEjX2L0uxsXhO8Q@mail.gmail.com> <CALTJjxHeJ8WVuaTfSa5G7xQ1F21VRpYuQ0nDsym8vGL_MOrEVQ@mail.gmail.com> <op.w30xbev03dfyax@killashandra.invalid.invalid> <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de> <5245F1DE.10903@gmail.com>
In-Reply-To: <5245F1DE.10903@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.227]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C6B63A00F1CA8244A46E959A39B30901@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2013 21:25:03 -0000

On Sep 28, 2013, at 12:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
> 
> Hi Hanno,
> 
> Just a few weeks ago we as a community thought the server's private key was generally secure.

Did we? Private keys are just files on a web server. Sometimes they leak ([1])

> Now the entire community seems to assume the private key is easy to steal.

Easy or hard depends on the practices of the web server administrators. I personally (and maybe others feel the same) think it's easier than factoring a 2048-bit number (or even factoring a 1024-bit number, or calculating a discrete logarithm in a 1024-bit MODP group). I understand it's problematic comparing unlike things, like what's easier: peace in the middle east or a manned flight to Mars? But when assessing risks to your website, you do have to figure out where to invest your resources.

> Practically, most private keys will probably not be stolen. OTOH the NSA (and also much smaller organizations) will have a pile of DH-1024 encrypted traffic for years to come just waiting for compute power to enable decryption en masse.

The longer they wait, the less valuable decrypting them becomes. And storing that pile costs them. Also, what do you mean by "en masse". If the entire traffic on the Internet was encrypted with DES (broken by civilians over 18 years ago), could the NSA afford to decrypt it all today?

> I'm sure you're not seriously suggesting that if I have a 3072-bit RSA cert, but my crypto library can only do 2048-bit DH, then I should never do DHE, and instead fall back to simple RSA, are you? Looking forward, there will always be mismatches and we should prefer the best possible TLS "mix", rather than enforce an idealistic policy.

That I agree with, but rather than optimizing mixes, I prefer to think of it as a minimum level for each primitive, and mandating at least that. An RSA ciphersuite has zero bits for PFS. Obviously, 1024-bit DH is better than zero bits (80 bits according to NIST estimates). If for various legal, commercial and BC reasons we can't mandate the 112 bits of 2048-bit DH or the 128 bits of ECDHE with the P-256 or equivalent brainpool curve or some other curve, then we should set the minimum level for now at 1024-bit DHE.

Yoav

[1] http://www.net-security.org/secworld.php?id=11144