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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 25 July 2014 05:13 UTC

Return-Path: <dkg@fifthhorseman.net>
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 4861D1A0306 for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 22:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tWf02KWcBXdN for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 22:13:29 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B43531A0AD6 for <tls@ietf.org>; Thu, 24 Jul 2014 22:13:29 -0700 (PDT)
Received: from [10.0.1.131] (173-230-166-62.cable.teksavvy.com [173.230.166.62]) by che.mayfirst.org (Postfix) with ESMTPSA id 61476F984; Fri, 25 Jul 2014 01:13:26 -0400 (EDT)
Message-ID: <53D1E776.40706@fifthhorseman.net>
Date: Fri, 25 Jul 2014 01:13:26 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cRNcwohmdvTLgj3jFDRjNNWGAQhMfSdaV"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-dYTlTLogRvRfKa71G3R65LYLTA
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: Fri, 25 Jul 2014 05:13:31 -0000

On 07/24/2014 10:53 AM, Peter Gutmann wrote:
> - 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?

There's a possibility that a very expensive (e.g. precomputation) attack
exists that can be mounted against any given group.  If we reuse the
same group used by other mechanisms (e.g. ipsec) then the value for
mounting such an expensive attack goes up.

Selecting a different group forces an attacker to choose which group to
attack.

> - What's the thinking behind a 2432-bit group?  2048-bit I could understand,
> 2560 bits perhaps, but 2432?

This was based on the 112-bit symmetric equivalence published by ECRYPT
II.  The ECRYPT document is referenced in the draft.

> - 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.

by q i think you mean (p-1)/2 -- i'm happy to document those values
explicitly in the draft if you think that would be useful.

Regards,

	--dkg