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

Andrey Jivsov <crypto@brainhub.org> Thu, 24 July 2014 20:45 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82411B28E7 for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 13:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmYU7piVtZNj for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 13:45:37 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26A71B28E8 for <tls@ietf.org>; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id rd18so2847119iec.28 for <tls@ietf.org>; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.50.110.103 with SMTP id hz7mr18692367igb.10.1406234736146; Thu, 24 Jul 2014 13:45:36 -0700 (PDT)
Received: from [31.133.163.98] (dhcp-a362.meeting.ietf.org. [31.133.163.98]) by mx.google.com with ESMTPSA id il3sm26620536igb.1.2014.07.24.13.45.34 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:45:35 -0700 (PDT)
Sender: Andrey <andrey@brainhub.org>
Message-ID: <53D17069.9060501@brainhub.org>
Date: Thu, 24 Jul 2014 16:45:29 -0400
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> <E293BCD4-46DB-4F5D-94EE-0ABA752949ED@gmail.com>
In-Reply-To: <E293BCD4-46DB-4F5D-94EE-0ABA752949ED@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WuJhW7zcmmDEQHCNzXQcLZFeZuQ
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
X-BeenThere: tls@ietf.org
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." <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: 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 <pgut001@cs.auckland.ac.nz> wrote:
>
>> <internet-drafts@ietf.org> 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.

Pros:
* 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

Cons:
* 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. )