[TLS] DHE key derivation

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 27 September 2013 15:08 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DCAB911E8160 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 08:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Sj4UaYHwz1l9 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 08:08:19 -0700 (PDT)
Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1170D11E814E for <tls@ietf.org>; Fri, 27 Sep 2013 08:08:03 -0700 (PDT)
Received: by mail-ea0-f181.google.com with SMTP id d10so1263484eaj.26 for <tls@ietf.org>; Fri, 27 Sep 2013 08:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=unxE/cSHKvp7MMyg/GJ7tbiH5FQW9HHJ3Vdxe/QOf3g=; b=C7t9cVYfcbj5+6fRbMAIMz53T/iDFF64bVWJ6qpH0I/GVrv0l7/H9pVz2idmCR6kzs 75R96JBsmUhSIKMfsqCJlAJ38bHVHhYYB4D63Nbm+syklDA0MNYM6siEecADME7wQP7N qe6j9Qpfk+JrDBN/jTYbJpDqrCWs0drwqUClFyF0JdEqSKgDrBR0Ml8KvqZahX3mQesN 1HbWgyMdDb9A7CLZ6vdkVwkv+JDnwa7jYkJcByG9MHi3zGFMZ994FEqPMSKaplQr4tj5 KFHDj49YcH7j+dvbpO0pM0n0mTdiMoDrD8QMS8t6LHe9+eINNbcV6Db8qCX8XoLu6l0P D8bA==
X-Received: by with SMTP id v45mr4850536een.52.1380294471280; Fri, 27 Sep 2013 08:07:51 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPSA id a43sm17147368eep.9.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 08:07:50 -0700 (PDT)
Message-ID: <52459F3E.2050101@gmail.com>
Date: Fri, 27 Sep 2013 18:07:42 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, "Yngve N. Pettersen" <yngve@spec-work.net>, "<tls@ietf.org>" <tls@ietf.org>
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>
In-Reply-To: <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [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 15:08:20 -0000

While we're opening (maybe) the negotiation of DHE, I'd like to clarify 
an issue that bothers me in the implementation of DHE in TLS:

With DHE, the premaster secret depends only on the DH shared secret. We 
know that DHE is commonly used with 1024-bit parameters. So even if you 
have a 2048-bit RSA certificate, the session strength will be 1024 bits.

What if we mixed *both* the DH secret and the regular encrypted nonce 
that's used in RSA ciphersuites into the premaster secret? Wouldn't we 
get forward secrecy, as well as crypto strength equivalent to the higher 
of the two lengths?


On 09/27/2013 04:48 PM, Yoav Nir wrote:
> On Sep 26, 2013, at 6:00 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote:
>> Hi,
>> On Thu, 26 Sep 2013 16:51:43 +0200, Wan-Teh Chang <wtc@google.com> wrote:
>>> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>>> My understanding of the 1024 bit Ephemeral DH key issue is that it is not
>>>> currently possible to use longer keys because a certain number of deployed
>>>> Web servers will abort the connection if a client presents a longer key.
>>> The size of ephemeral DH keys is specified by the server, and the
>>> client must present a key of that size. (This doesn't change the
>>> problem though.)
>>> The client needs a way to negotiate the ephemeral DH key size (or the
>>> DH domain parameters) with the server. This can be done by either an
>>> extension (similar to the elliptic_curves extension of RFC 4492 for
>>> ephemeral ECDH keys) or new cipher suites.
>> In my opinion the length of the DHE key should have at least the same length (number of bits) as the signing RSA key. And similar for ECDHE, if necessary.
> Not for ECDHE_RSA, though. That would require that we define what ECDHE curve is equivalent to X-bit RSA.
> In general I don't like us doing the NIST magic tables of naming equivalent strength key lengths among different algorithms, as in 1024-bit RSA is similar to some non-existing 80-bit perfect symmetric algorithm, and a 1024-bit MODP group is sort of like that.
> Yoav
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls