Re: [TLS] DHE key derivation

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

Return-Path: <yaronf.ietf@gmail.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 C40E721F9E54 for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 14:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.362
X-Spam-Level:
X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 6w1b4KyYBB1C for <tls@ietfa.amsl.com>; Fri, 27 Sep 2013 14:00:19 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7132621E8095 for <tls@ietf.org>; Fri, 27 Sep 2013 14:00:17 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cb5so1388420wib.5 for <tls@ietf.org>; Fri, 27 Sep 2013 14:00:16 -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=FSv14RQfZTtv7NyKdTElhu1jN4b6pYK34bQBD+NTZ7c=; b=sjCIGWW7nCmmANoXBjGMoVNy6q31tA6/d3u1MWXwWGJabvw0Tw4gAi3aABHkFa+bKo VLwwNuTWt6UEIj4pDmN6y4xzoJ7VqPtB//rRiftQJDx4hS8Tu2le1rg5wJmdNNftYQnP 4H2qdNgUmK2f8hD82zm4Kgupe4pt8cpE33gWyPOr9tse8ENp8pNjKvHKGA2ulMXEPgpS V/yzYvpBu2+5ppo4rmgxisJU1+DOs61kOhDUELTrdPVsTnz4UEndyjn0lDXhzcLrpo82 g37i/ihCilurFIC3gW8GXtYJ248jtegH3cuH4ncXSkXvWkQSn3vEQ9PBVFfd8YhtfYQN Hb7A==
X-Received: by 10.194.158.67 with SMTP id ws3mr7405944wjb.5.1380315616559; Fri, 27 Sep 2013 14:00:16 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id dq11sm42118314wid.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 14:00:15 -0700 (PDT)
Message-ID: <5245F1DE.10903@gmail.com>
Date: Sat, 28 Sep 2013 00:00:14 +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: =?ISO-8859-1?Q?Hanno_B=F6ck?= <hanno@hboeck.de>, 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> <52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de>
In-Reply-To: <20130927185535.5b971c1d@hboeck.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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:00:20 -0000

On 09/27/2013 07:55 PM, Hanno Böck wrote:
> 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)
>
Hi Hanno,

Just a few weeks ago we as a community thought the server's private key 
was generally secure. Now the entire community seems to assume the 
private key is easy to steal. 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.

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.

Thanks,
	Yaron