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

Brian Smith <brian@briansmith.org> Wed, 10 December 2014 06:34 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D49B21A1B9A for <tls@ietfa.amsl.com>; Tue, 9 Dec 2014 22:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 56BM1SKLelLU for <tls@ietfa.amsl.com>; Tue, 9 Dec 2014 22:33:51 -0800 (PST)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783E91A1B73 for <tls@ietf.org>; Tue, 9 Dec 2014 22:33:51 -0800 (PST)
Received: by mail-ob0-f178.google.com with SMTP id gq1so1743020obb.23 for <tls@ietf.org>; Tue, 09 Dec 2014 22:33:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IHCB48ljxE5DZn6RgQMXns4pSZDz7lGOB207fe7t+DY=; b=IpMBedvZPmZEzK98dZz5j4LG/5bMWhoem5TBpECf479JGdhjKZ1P/cjfLo7N9gvWJp nfFJ3dsVNSORLdh72m1GKIf3Ke+dVyeEsgkn1LJD9+UdVxunhSrATYM8NHP+5aqbwNK1 dnGVYkXpVg61kZHSlhP4hqe9t+YvmiUdve6J4fL2rjgB3e0MF1KlCKJ1c+b3rA1Ncsro 6l6sG8LkK4rJEE9oEeTwxrdsOxkRSLmq5tCi8cg+rmD+P9cF1CgDd6fsrMrFKGPufETQ ZkuptCvIHCCOAHgFIyGUFLFQmWvQFHPS2jUELlBdiGX1JKns93RKGBwoLmKvcRmNGVP+ +iXg==
X-Gm-Message-State: ALoCoQnnfi5krWyuo4/mq53y3X6R+i7jdlMKktawxU8e0Skqg3kpsOSIwxAl5fSRlPVt7wnEjYbE
MIME-Version: 1.0
X-Received: by with SMTP id q7mr1549697obq.28.1418193230987; Tue, 09 Dec 2014 22:33:50 -0800 (PST)
Received: by with HTTP; Tue, 9 Dec 2014 22:33:50 -0800 (PST)
Date: Tue, 09 Dec 2014 22:33:50 -0800
Message-ID: <CAFewVt4J4TdBa9tzzhmpU6rpwrbHXGpiSLeQNDUbQZEosFUtdg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-9orxj7fDpNqJoT3m-W5G8HEIwc
Subject: [TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension
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: Wed, 10 Dec 2014 06:34:02 -0000

* The vast majority of servers that pick DHE key exchange, in Firefox
at least, are using 1024-bit *or smaller* DHE keys, and/or keys with
other problems.

* It may be the case that the server is configured with good ECDHE
parameters and DHE parameters that aren't as strong as the ECDHE
parameters. In fact, most servers that support both ECDHE and DHE key
exchange seem to be configured like this: P-256 for ECDHE, and
1024-bit keys for DHE. (Note that the key size may not be the only
issue with the DHE parameters, and that the possible problems with DH
parameters other than key size are difficult and/or very expensive to
check.) An attacker can modify the ClientHello to trick such a server
into choosing its weak DHE parameters instead of its strong ECDHE

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

* Firefox and Chrome (IIUC) are both removing support for DHE_DSS key
exchange, due to non-use by servers and/or too-small key DSS key sizes
(almost always 1024 bits). Obviously, there are other implementations
to consider, but I think the reasoning behind the Firefox and Chrome
decisions likely applies to most/all other implementations that would
do False Start.

Because of the above issues, the False Start draft should be changed
to remove DHE_RSA and DHE_DSS from the list of recommended key
exchange algorithms, leaving only ECDHE_RSA and ECDHE_ECDSA in the