Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Michael D'Errico <mike-list@pobox.com> Sun, 22 September 2013 04:47 UTC

Return-Path: <mike-list@pobox.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 E32D521F8F4A for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 21:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level:
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599]
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 R0JGy5xrWyWY for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 21:46:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2582621F8F2E for <tls@ietf.org>; Sat, 21 Sep 2013 21:46:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3047CEAB7; Sun, 22 Sep 2013 00:46:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=q00bSPBN37SX bzQKiE/pyLg8fJA=; b=UOsq13/tVjztPyVDmJCdOaaLVoXusEFYsKzjyO9Nr73C SoFo9m/R5vfBt1IRcC/w45vzVOb139Szn0BNkfj4pmbJh+G25XpZS1tFBDbzNBFs pktmFsLXuDLmKQOL4whiAyUUcXl4tJKZiAMnziUhPLA6QMKrExiHVBsF5gHuYxg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=L5BDi1 NdgqMVBl6hjkmEbG/hTxLapXobCkgdpV6TKGM786bHxO6Z1x3RnymAnzJOMOCg8r 7zPYGj1j10/nue91vjlzaA6VTXafjIvf0kpGQ8jrdwqzQqChWtpnPTwY0OtDyZkx AFFWqYxtuefUOC0WCQQNU+4Pg9AvLXxNGVUVk=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2944FEAB6; Sun, 22 Sep 2013 00:46:54 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9B7ECEAB5; Sun, 22 Sep 2013 00:46:53 -0400 (EDT)
Message-ID: <523E763C.1010701@pobox.com>
Date: Sat, 21 Sep 2013 21:46:52 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
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>
In-Reply-To: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 00B76A48-2342-11E3-BE7B-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] 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, 22 Sep 2013 04:47:02 -0000

Yoav Nir wrote:
> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <code@funwithsoftware.org>; wrote:
> 
>> We *do* know how to move to 2048 bits without breaking anything: add an extension to negotiate DH size, just like how ECC curves are negotiated.  Although yes, this will take a while to deploy universally, it at least means early adopters can start using 2048 now, without breaking the stragglers like Java.
> 
> Perhaps it would be better to have the client suggest the actual group rather than bit length in that case. Perhaps we could reuse the IKE numbering of groups, or else have the client specify it similar to ServerDHParams struct.

If the client chooses, then I'd prefer they choose from a list of
standardized groups similar to RFC 3526 rather than requiring the
server to (try to) verify that the parameters are usable.  We could
also sneak in a 256-bit q parameter to speed up the computations.

Mike