Re: [TLS] DHE key derivation

Hanno Böck <hanno@hboeck.de> Fri, 27 September 2013 16:55 UTC

Return-Path: <hanno@hboeck.de>
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 6866C21F9F45 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 hPZwWcUMsroq for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 09:55:44 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7017721F9D2A for <tls@ietf.org>; Fri, 27 Sep 2013 09:55:43 -0700 (PDT)
Received: from localhost (91-66-72-107-dynip.superkabel.de [::ffff:91.66.72.107]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Sep 2013 18:55:40 +0200 id 00000000000000B1.000000005245B88C.00006FA9
Date: Fri, 27 Sep 2013 18:55:35 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20130927185535.5b971c1d@hboeck.de>
In-Reply-To: <52459F3E.2050101@gmail.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>
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-28585-1380300940-0001-2"
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 16:55:49 -0000

On Fri, 27 Sep 2013 18:07:42 +0300
Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

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

I feel this would add even more confusion.

What you'd get:
- Connection Security of the RSA key size, BUT
- Forward Secrecy only with the security of the DHE modulus size

Or to be concrete: an attacker able to steal the certificate's key
AFTER recording a connection and at the same time being able to break
the DHE would still be able to decrypt.

I don't really get why that should make any sense. Okay, it would avoid
that DHE "downgrades" the security of the RSA key.
But: This would require changes to the protocol. Won't work with
existing software, so it won't solve the mess we have today.

If you are already changing the protocol, you can also do something
that makes much more sense: Forbid DHE modulus size smaller than RSA
key size. (which also could be achieved just by server policy without
protocol changes, but then breaks messy clients like java - see past
discussion)

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42