Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]

Patrick Pelletier <code@funwithsoftware.org> Sun, 10 November 2013 05:34 UTC

Return-Path: <code@funwithsoftware.org>
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 9554321E80E8 for <tls@ietfa.amsl.com>; Sat, 9 Nov 2013 21:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 QmYGIP+E323s for <tls@ietfa.amsl.com>; Sat, 9 Nov 2013 21:34:28 -0800 (PST)
Received: from mail24c25-2209.carrierzone.com (mail223c25.carrierzone.com [64.29.147.237]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1421E80E6 for <tls@ietf.org>; Sat, 9 Nov 2013 21:34:28 -0800 (PST)
X-Authenticated-User: ppelleti.speakeasy.net
Received: from PatrickMBP.local (dsl017-096-185.lax1.dsl.speakeasy.net [69.17.96.185]) (authenticated bits=0) by mail24c25-2209.carrierzone.com (8.13.6/8.13.1) with ESMTP id rAA5Y9dq002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 05:34:23 +0000
Message-ID: <527F1AD1.20804@funwithsoftware.org>
Date: Sat, 09 Nov 2013 21:34:09 -0800
From: Patrick Pelletier <code@funwithsoftware.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com> <87d2mcy2s3.fsf@alice.fifthhorseman.net>
In-Reply-To: <87d2mcy2s3.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CSC: 0
X-CHA: v=2.1 cv=aKDJ99Nm c=1 sm=1 tr=0 a=3bGt9MXpJgS1DxBngKRbCQ==:117 a=3bGt9MXpJgS1DxBngKRbCQ==:17 a=eVbW6KzvAAAA:8 a=g0qM3YM6AAAA:8 a=Nj7kusMiCPUA:10 a=XwRAJLFUau8A:10 a=rtZ2W72OR7QA:10 a=8nJEP1OIZ-IA:10 a=SF9KqDZ7AAAA:8 a=MlwnRRhLUwgA:10 a=gHvrztcjAAAA:8 a=X5UvlbiVwI_kCvQgiB0A:9 a=wPNLvfGTeEIA:10 a=yl1PmSW91XoA:10
X-CTCH-RefID: str=0001.0A020203.527F1AE0.0096, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
Subject: Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
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: Sun, 10 Nov 2013 05:34:33 -0000

On 11/7/13 1:33 AM, Daniel Kahn Gillmor wrote:

> The minmalist proposal:
> -----------------------
>
>   * compliant clients advertising a ciphersuite using EDH would include
>     an extension indicating the smallest and largest EDH group sizes they
>     are willing to accept.

The only thing I would add is that besides minimum and maximum number of 
bits, the client should also indicate a multiple, which the group size 
must be divisible by.  For example, Java only supports DH groups whose 
size is a multiple of 64.  If the client can accept any group size 
within its minimum,maximum range, then it uses 1 as its multiple.  So, 
examples of this triple might be:

1024,2048,64
1280,4096,8
1024,8192,1

> All of the observations above make me think that the minimalist proposal
> seems to be the least likely to cause controversy and the simplest to
> patch into existing implementations quickly and safely.

+1.  It just fixes the existing mechanism, rather than introducing a new 
mechanism.

However, at the risk of making the minimalist proposal slightly less 
minimal, I'd like to suggest that the extension should also allow the 
server to reply with the DH exponent size:

http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html

--Patrick