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

Peter Gutmann <> Tue, 29 July 2014 13:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B16881B288F for <>; Tue, 29 Jul 2014 06:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5_g7RiMzQfh4 for <>; Tue, 29 Jul 2014 06:10:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F4181B288C for <>; Tue, 29 Jul 2014 06:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1406639431; x=1438175431; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lk+ON9jvPtSY0dfiX4IyT3h2HaqCXlSEny7zuqYd0Co=; b=iVHbZWN27365ts0oJ+xrLv6s4IwF5jAzAOj1lBX0JOhi4eadnab5U1o1 JDB6LkCf2TuVSWYNUfvwkiY7SoFxMefU2iklug/8fWIqYHAljQOGWN/2t ZrcUJ5jQ5ouRXRWLWSoXOxd7jUv5unVdowhfkn6elva4mHisg0ZSutT1x U=;
X-IronPort-AV: E=Sophos;i="5.01,757,1399982400"; d="scan'208";a="266221078"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 30 Jul 2014 01:10:29 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 01:10:28 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
Thread-Index: Ac+rLneaIDKRPxLtSG2nX15VP8eJJw==
Date: Tue, 29 Jul 2014 13:10:28 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jul 2014 13:10:36 -0000

Daniel Kahn Gillmor <> writes:

>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

Yeah, I can see that, but it's a bit of a hypothetical attack, we have no way
to quantify the risk.  For something like "don't use the same key to encrypt
and MAC" there's a clear, well-known threat, but for "don't use the same key
(DH group) for IPsec and TLS" it's really just speculation.  Once you start
down this path, where do you stop?

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

Is there really any good reason to want to match group size to algorithm key
sizes, and (I'm assuming for a 112-bit key) one for an obsolete (if still
widely-used) block cipher?  I'd just pick some standard group sizes (1K, 2K,
3K, 4K) and go with those as general-purpose solutions rather than selecting
oddball sizes to match some particular other algorithm.

(Where did the fashion of specifically choosing the hat to match the shoes
come from in crypto?  AFAIK it's NSA-originated from things like the original
DSA's hardcoding of the SHA-1 blocksize into the algorithm, and KEA and
Skipjack key sizes.  I've never been able to understand why something like a
particular cipher block size needs an entire range of fashion accessories to
go with it, if an n-bit prime is good enough for a 256-bit symmetric algorithm
then it should also be good enough for 128 bits, 192 bits, and 77 1/2 bits).

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

Yes, thanks.