Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt

Andrey Jivsov <> Thu, 24 July 2014 20:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A82411B28E7 for <>; Thu, 24 Jul 2014 13:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WmYU7piVtZNj for <>; Thu, 24 Jul 2014 13:45:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E26A71B28E8 for <>; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
Received: by with SMTP id rd18so2847119iec.28 for <>; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QrIS4t7/NegDf40QkTYZToYtLXLq7c7xhZoQIEnat0c=; b=eiU9wt+32B/nA3yjKQZRrsTM3T0MJDu1FiIhi9kKYurbu40B12OqBRcFc/H/dGUzZ+ MnC3fIZQKfB3XbVz7KCUmyX7tk3Q7EOq3/x/wa7l2jY4EfeiVJywed0ILVIiewm28v7+ dGbVzW/u9pkIgJGXCCxfLbIxH0yeQlc3cbAJRP+vqP3WpuTxCuVk08PD0PbWLoBh/CXI VcYi+kkakGo5HSRVKqPy5tVBcFlHkzOZZtLKoY1c7mpY+TcumncRvXq+q7xB8ntLVFdU mxQRMrCYHkO8XAUh2qbsRF+bZ9hg+bWMsm308C3fCa2k2jS91b1Zz4sn6+PNL5gqrmFZ j+Dw==
X-Gm-Message-State: ALoCoQn4CaYQC0yeFkz4MDOLKiT5yKN5AcvPzcaXOM/LgTiun+7rwLkwwWfwWvAEs0GvtAipMF7O
X-Received: by with SMTP id hz7mr18692367igb.10.1406234736146; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id il3sm26620536igb.1.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:45:35 -0700 (PDT)
Sender: Andrey <>
Message-ID: <>
Date: Thu, 24 Jul 2014 16:45:29 -0400
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 20:45:38 -0000

On 7/24/2014 2:00 PM, Yoav Nir wrote:
> On Jul 24, 2014, at 10:53 AM, Peter Gutmann <> wrote:
>> <> writes:
>>>   Traditional finite-field-based Diffie-Hellman (DH) key exchange
>>>   during the TLS handshake suffers from a number of security,
>>>   interoperability, and efficiency shortcomings.  These shortcomings
>>>   arise from lack of clarity about which DH group parameters TLS
>>>   servers should offer and clients should accept.  This document offers
>>>   a solution to these shortcomings for compatible peers by establishing
>>>   a registry of DH parameters with known structure and a mechanism for
>>>   peers to indicate support for these groups.
>> Some comments:
>> - Why not just use the well-known and -accepted IKE groups from RFC 3526 for
>> this?  In fact why invent entirely new groups (that don't even cover the
>> existing range in RFC 3526) when there's already well-established ones
>> available?
> That’s been asked at the meeting. No particular answer.

* a resourceful attacker will not be able to look for collisions within 
a single database of (key, key*G). He needs two, for IKE and TLS.
* this adds one bit of security

* It adds only one bit of security
* an implementation that shares code between IKE and TLS will need to 
store an additional hardcoded prime.

Most people will not have strong preferences here, I assume.

>> - What's the thinking behind a 2432-bit group?  2048-bit I could understand,
>> 2560 bits perhaps, but 2432?
> I asked that at the meeting. The answer is that this number supposedly exactly matches the 112-bit level of security.
IMO this comes down to alignment with other standards and practice.

If 2048 RSA is being paired with dldhe2432, this would waste ~400 bits.

More generally, deviating from 2048, 3072, 4096, etc will result in a 
similar waste of resources and add to uncertainty on how to match security.

Second, the map between the bit security and modp size has been a 
dynamic quantity over the years. There bring another benefit to stick 
with a round number: longer shelf life of the document.

>> - Publishing the values of q (rather than just telling people how to calculate
>> them) would be good, since it'd provide known-correct values for them.
>> In general though, we don't need yet another set of parameters, all that's
>> needed is a mechanism for specifying the existing RFC 3526 groups.
> And that’s assuming we even want FFC parameters (as opposed to ECC).
There is a benefit for TLS 1.2 and earlier versions. It should be at 
least MAY in 1.3 to assure smooth transition.

( Although this only matters for reused KE parts, we get an 
exceptionally cheap validation that that the peer's part belongs to a 
large subgroup, almost for free. )