Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension

Brian Smith <> Tue, 16 December 2014 05:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7AE481A038E for <>; Mon, 15 Dec 2014 21:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d3MRZ9HC7GkE for <>; Mon, 15 Dec 2014 21:45:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9EF21A037A for <>; Mon, 15 Dec 2014 21:45:22 -0800 (PST)
Received: by with SMTP id g201so271368oib.26 for <>; Mon, 15 Dec 2014 21:45:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rrniMZIVRu7HUMWf+9FCYe0nTCwH/abw5jHFimyuGLQ=; b=W3zMqqAEoarCQwTG3rKOh2pjgaxu7hhfLHCelJRcUfKfPsIgFkqUt+OQ9Hl5oVEccz iyCAj2HLQyAxGJYdcm+3OIU+Ez296dOOYQgDbYogdR8u1DuPS4yLmZyjCUUAXBTOkktw htBrO35iziBuSsM38tUkSp6D+hsJovY1xlYUoHEy8CPIuW3yoPV5xIb5o3WDpMj90m37 AkPJon5qRh1Q3xEnjyIpdbUuhspybfKLQEmwVo4jJ4z6+TrF1GpBpTLvCA1aVraJxepn jteZRrZf4/2jNCT0rNed5n4FUzv4QB6WLXUrlR2/HGlHw2H5PU/RFTOMkZ8Ubdn5A35W dN0w==
X-Gm-Message-State: ALoCoQmBC7EqjICIXT3lmTPKI+p0qQMl/LyI3k2ty276RRiTr6SmrleS9i+H0W/hefkBYT3fE/So
MIME-Version: 1.0
X-Received: by with SMTP id a62mr20644716oif.92.1418708713781; Mon, 15 Dec 2014 21:45:13 -0800 (PST)
Received: by with HTTP; Mon, 15 Dec 2014 21:45:13 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 15 Dec 2014 21:45:13 -0800
Message-ID: <>
From: Brian Smith <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset="UTF-8"
Cc: "<>" <>
Subject: Re: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension
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, 16 Dec 2014 05:45:24 -0000

On Wed, Dec 10, 2014 at 12:27 PM, Daniel Kahn Gillmor
<> wrote:
> On 12/10/2014 01:33 AM, Brian Smith wrote:
>> * The Negotiated FF-DHE draft mechanism is specified in such a way
>> that the server's signature on DHParams does not cover the client or
>> server FF-DHE extensions,
> There are no FFDHE-specific extensions in the draft, just a reuse of
> NamedCurves on the client side to specify FFDHE groups.

Understood. Sorry for being lazy with the terminology there.

>> because the definition of DHParams was not
>> modified to cover them. This is unfortunate, because it means that
>> these parameters, and thus the entire DHE exchange, cannot be fully
>> validated until the peer's Finished message is validated.
> If there is a change in the way that you think the signature should be
> processed in draft-ietf-tls-negotiated-ff-dhe, please suggest a concrete
> change.

I do not think a change to draft-ietf-tls-negotiated-ff-dhe is needed.

>> In particular, this means that the FF-DHE mechanism, as currently
>> designed, is not useful for enhancing the security of False Start
>> handshakes that use DHE key exchange.
> I'm not sure i reach the same conclusion.  consider it from both sides:
>  * full handshake, client sends first
>    In this situation, the client sent the server a list of preferred
> FFDHE groups.  the server either responded with one of them, or did not
> respond with one of them.  If the server responded with one of them, and
> it was signed by the server's validated public key, why should this
> preclude the use of FalseStart by the client?  The server replied with a
> value from an acceptable group, and the message (including client and
> server randoms for freshness) was signed by the server.  Why should a
> client refuse to send traffic early in this case?

The MitM may have tampered with or removed the FFDHE groups from the
extension in the ClientHello, misleading the server into thinking the
client's capabilities are weaker than they actually are, and thus
causing the server to choose weaker DHE parameters. The tampering will
be detected by the server when it validates the Client's Finished
message, but by that time the client will have already sent data
encrypted with keys derived from the weak DHE key material.

> Perhaps the false start draft should say that a client shouldn't do
> false start for a server that offers FFDHE but does not send an
> acceptable named group.

I agree that the client could maintain a whitelist of
false-start-acceptable FFDHE groups, which should be a subset of the
FFDHE groups listed in its supported curves extension. However,
wording to that effect, and wording about how to compare the strength
of ECDHE groups to FFDHE groups, should be included in the draft if
FFDHE support is going to continue to be recommended. IMO, FFDHE is
basically obsolete now, so it isn't worth the effort to do this.
However, I understand that others might disagree.