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

Geoffrey Keating <> Wed, 03 June 2015 06:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 39E841B359A for <>; Tue, 2 Jun 2015 23:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mABjz9KBVRvv for <>; Tue, 2 Jun 2015 23:32:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BB461B357A for <>; Tue, 2 Jun 2015 23:32:12 -0700 (PDT)
Received: by (Postfix, from userid 501) id 6D24233D1E3; Wed, 3 Jun 2015 06:32:11 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Tony Arcieri <>
References: <> <> <> <>
From: Geoffrey Keating <>
Date: 02 Jun 2015 23:32:11 -0700
In-Reply-To: <>
Message-ID: <m2lhg1b8us.fsf@localhost.localdomain>
Lines: 31
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <>
Cc: TLS WG <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.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: Wed, 03 Jun 2015 06:32:13 -0000

Tony Arcieri <> writes:

> So I am very, very, very confused about what argument you're trying to make
> about Java here. As far as I'm concerned the *only* workable solution for
> older Java clients is to shut DHE off.
> Can you please explain to me where in this draft I can locate the part
> about how it will help older Java clients better participate in the TLS
> ecosystem, because I can't find it.

It's covered in section 4:

   If at least one FFDHE ciphersuite is present in the client
   ciphersuite list, and the Supported Groups extension is either absent
   from the ClientHello entirely or contains no FFDHE groups (i.e. no
   codepoints between 256 and 511 inclusive), then the server knows that
   the client is not compatible with this document.  In this scenario, a
   server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE
   ciphersuite and offer an FFDHE group of its choice to the client as
   part of a traditional ServerKeyExchange.

In this case, and I think most of the time, a server should choose the
first of the two MAYs: offer a non-FFDHE ciphersuite.  This has the
effect of shutting FFDHE off for those older clients but allows you to
continue to offer stronger FFDHE to newer clients (if they for some
reason won't do ECDHE).

The old-client compatibility story with this draft is quite strong.
Alas the old-server compatibility story is not so strong; a new client
with an old server might get proposed an insecurely small FFDHE field,
and have to reject it and reconnect.