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

Peter Gutmann <> Thu, 24 July 2014 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6D9B91A03D6 for <>; Thu, 24 Jul 2014 07:53:58 -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 KcH7-0WmH1lv for <>; Thu, 24 Jul 2014 07:53:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28ACE1A03C2 for <>; Thu, 24 Jul 2014 07:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1406213632; x=1437749632; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=M8iyxcjjZItqyG7cgq8m6s5n/21KNJ0odB1GGxW3hT0=; b=fw5gMAaB6JRSBwou5vjXNoWxZKcYm6e4T0FCgrXP8rR3kQAw8msqre3s keDEef+LSXeR6Rc+Nf5JwLwv9to24zcwSdRRUBhdSwJN0S3rvJgbxET2T oPUv1VC32m4huvT9XQZrtDz9fxrvQej1XJX6ZGP2dGjdfUetyqnEORR3A k=;
X-IronPort-AV: E=Sophos;i="5.01,724,1399982400"; d="scan'208";a="265551589"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 25 Jul 2014 02:53:47 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 02:53:46 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
Thread-Index: Ac+nTxIDPv2cUlFtTNOADpXqJ0CiGQ==
Date: Thu, 24 Jul 2014 14:53:46 +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: Thu, 24 Jul 2014 14:53:59 -0000

<> writes:

>   Traditional finite-field-based Diffie-Hellman (DH) key exchange
>   during the TLS handshake suffers from a number of security,
>   interoperability, and efficiency shortcomings.  These shortcomings
>   arise from lack of clarity about which DH group parameters TLS
>   servers should offer and clients should accept.  This document offers
>   a solution to these shortcomings for compatible peers by establishing
>   a registry of DH parameters with known structure and a mechanism for
>   peers to indicate support for these groups.

Some comments:

- 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

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

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

In general though, we don't need yet another set of parameters, all that's
needed is a mechanism for specifying the existing RFC 3526 groups.