Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart

Brian Smith <> Wed, 01 April 2015 20:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C000D1A908A for <>; Wed, 1 Apr 2015 13:16:09 -0700 (PDT)
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 o8chee2fNXRh for <>; Wed, 1 Apr 2015 13:16:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0161F1A90CE for <>; Wed, 1 Apr 2015 13:16:04 -0700 (PDT)
Received: by obbfy7 with SMTP id fy7so12587821obb.2 for <>; Wed, 01 Apr 2015 13:16:03 -0700 (PDT)
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=toAxL1zZNEkKbhNeqXHgn3I83n0yE5nt/CJAKHh2x1w=; b=Vl4pWyaZSx72DUT4g/HVQG03pgorz/KNt5PT6WUyLilWYkwcOYNNmEHsDO/pl9IrSC KcMY78n4Q1ZBMF9iRjI3dfPRDMuZ1c2Y1jNQ6Py3izZx7adPKzyLbkyLhOaUsdSkhpHz 2lUWSyW6broTh9BojREO9mnJziCyeCrwvyiYeECBOraFYUBwWL3vAID4VhZQsCvT6Spr FBKxBj2mYxIVgZ5r8ogsToaqOhok4SdFIg0cpB1TrqgPdiQz2ZtD4MzPA/UjMTCl39B6 51ixIJUmWhX+rTZfAKApJZSHez3VGDb7qBKU1DBA7JGeOCkS+pzG2iW9ppl5q35vjjS2 fujw==
X-Gm-Message-State: ALoCoQl5kE5NdBn1fAuEQA+A6KQehB6aqDclfyEvYOh7MPkjxRns3awk/hJbcdk/GeesIc5OKeQg
MIME-Version: 1.0
X-Received: by with SMTP id d15mr32147276obt.58.1427919363505; Wed, 01 Apr 2015 13:16:03 -0700 (PDT)
Received: by with HTTP; Wed, 1 Apr 2015 13:16:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 01 Apr 2015 10:16:03 -1000
Message-ID: <>
From: Brian Smith <>
To: Martin Thomson <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart
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, 01 Apr 2015 20:16:09 -0000

Martin Thomson <> wrote:
> On 31 March 2015 at 19:33, Brian Smith <> wrote:
>> 4. The references to (FF-)DHE key exchange being acceptable for False
>> Start are removed. Although it may be possible to safely implement
>> False start for FF-DHE, the current draft isn't a good starting point
>> for specifying how that might be done. It's better to remove the
>> references until an adequate description of doing False Start for
>> FF-DHE key exchange is available, if ever.
> I agree with most of what Brian says, particularly with respect to
> only accepting the "best" profile of TLS here.  However, I am
> generally leery of making specific recommendations regarding cipher
> suite choice.  With the explicit groups, this might be OK.  Without
> explicit groups, I think that Brian's point is completely valid.

Implementing the negotiated FF-DHE mechanism as specified definitely
isn't sufficient and may not be necessary for doing False Start with
FF-DHE cipher suites:

1 The negotiated FF-DHE spec still allows the client to use FF-DHE
parameters that it didn't send, in order to interop with
implementations, as long as it has some "policy" for handling that
case. For False Start, such a policy would have to be defined.

2. As I noted in the Firefox bug, even if the client only does False
Start with parameters it advertised in its FF-DHE extension, there is
still potential for material downgrade if the weakest FF-DHE
parameters it advertises are weaker than the ECDHE curves it supports.

3. Even if the client doesn't implement ECDHE at all, the weakest
FF-DHE key it offers during FF-DHE parameter negotiation may not be
strong enough to do False Start. Given the research I did for Firefox
that showed that any reasonably definition of "strong enough" is
practically equivalent to disabling False Start for FF-DHE, it seems
not to be worthwhile to bother trying to define "strong enough."