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

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 22 September 2013 05:39 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 ED5FF21F9CB1 for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 22:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level:
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, 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 Tvc59+ObTTGz for <tls@ietfa.amsl.com>; Sat, 21 Sep 2013 22:39:04 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8985021F9FAB for <tls@ietf.org>; Sat, 21 Sep 2013 22:38:58 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id q16so1018827ead.7 for <tls@ietf.org>; Sat, 21 Sep 2013 22:38:57 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pWPTjduEvqgltsLIDdCYzzBBfxf3eEqLfC1iQIvmdy4=; b=Fv39qwugIqrlpl3tcVWJ2RoF1l5k/r74imNMIQFF/JH2KhDfYqCb8PoXQrwug4cG8A nxwxgPktwXDF3ZWN5YtS16sJg5sqpUCMAmzHX2hurPSuJVnAlvG8Dh+xogrXyrS5lKi0 8rFZWWOT3hg9C5mg8bPvhpcRBElTcVFss3DUlkAiGpPufmI6deBFuNQ1uRCT+btvPGOv O1bsggiUQC5qVIT3Fevfj4ie6wxsc3/olYoYLg33l8qUuXwz1Np+0cbavkUPVBdIOLjs pidl2uQQ7ltGQkynZFGsdKWJJx3V7Gf+bWU+VsK2Kcozd7co2n1Xo64RYr7OfYuIDVnX 48dQ==
X-Received: by 10.14.109.66 with SMTP id r42mr935619eeg.43.1379828337409; Sat, 21 Sep 2013 22:38:57 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id a1sm31748380eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 22:38:57 -0700 (PDT)
Message-ID: <523E826F.2060500@gmail.com>
Date: Sun, 22 Sep 2013 08:38:55 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.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> <523E763C.1010701@pobox.com>
In-Reply-To: <523E763C.1010701@pobox.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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 05:39:06 -0000

I'm all for negotiating DH parameters. Life would have been much easier 
if we had it in TLS today.

But new extensions are out of scope for draft-sheffer-tls-bcp. We need a 
set of best common practices that people can actually deploy within the 
coming year, hopefully earlier.

Thanks,
	Yaron

On 09/22/2013 07:46 AM, Michael D'Errico wrote:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls