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

Brian Smith <> Wed, 01 April 2015 02:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9DE701A066C for <>; Tue, 31 Mar 2015 19:33:39 -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 D_2EYJ9fNOtp for <>; Tue, 31 Mar 2015 19:33:38 -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 16F5A1A00E5 for <>; Tue, 31 Mar 2015 19:33:38 -0700 (PDT)
Received: by obvd1 with SMTP id d1so58186842obv.0 for <>; Tue, 31 Mar 2015 19:33:37 -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 :content-transfer-encoding; bh=Q4stnLKNQ3ivl4grI+8tv/E7tHBF1aEvKI5gsRTPhgU=; b=IL8jUXS89Z33UBY5NLO80ORNDciW+d+YL/UJfPITvb51wZqw/EJ9dDjGFoiU/j3M1H 2d5n5EfQrhW1ApxwRtIOvTpIB49PYDqlSlcTROUZkiWSUTyGBnYinGoGQbbKCyZqd+oC Aik/lriGcw2BkNcQjI9iNWLzOfZjhjA7EyrgOSDnCZGwBtozNyBbW3U5M1Pa/rNw3UIV qBWuvRQeiHu/aNY7a7ymTTECoL3EH1HRr+oDX9w+N5IKQ9CCg8fL6peWbAPBpxyv+Nfg t/OKPHIgzev2KK4PJDxbUNNS61epD3zkrJo0DaLMT690TfXSIVZIm75wCuYO7KPCpyOy JLuQ==
X-Gm-Message-State: ALoCoQlN4N80WNDvog+Uvumoimpwmc7D00JZIGdPtHVOkHFLFUpLXb6zgDUoIxdmrXHPRAMo6ChA
MIME-Version: 1.0
X-Received: by with SMTP id g6mr37562310oej.7.1427855617438; Tue, 31 Mar 2015 19:33:37 -0700 (PDT)
Received: by with HTTP; Tue, 31 Mar 2015 19:33:37 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 31 Mar 2015 16:33:37 -1000
Message-ID: <>
From: Brian Smith <>
To: Sean Turner <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 02:33:39 -0000

Sean Turner <> wrote:
> There’s been some interested expressed in having adopted as a TLS WG item.  If you would like for this draft to become a WG document, and you are willing to review drafts as it moves through the process please indicate as much on this thread.  If you are opposed to this being a WG document, please say so (and say why). Thanks in advance.

I support adopting a new version of this draft that has made the
following changes:

1. The server-side False Start section is removed. I don't think it
has received enough scrutiny and it isn't worth the working group's
time to study and/or fix it.

2. The reference to TLS_FALLBACK_SCSV is removed and replaced with a
requirement that False Start is to be done only for TLS 1.2--not
earlier versions, and not later versions. As of Firefox 36, Firefox
only does false start for TLS 1.2 [1][2][3]. Google Chrome will be
doing similar soon [2], AFAICT for similar reasons to Firefox.

3. The text about doing False Start when sending client certificates
is removed. Not only is it not worthwhile as a performance
optimization, the whole idea of sending the client certificate in the
clear at all is a terrible idea that shouldn't be encouraged. (Firefox
has never done False Start when it sends a client certificate; I am
not sure about other implementations.)

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 believe we would save a lot of time if we adopted a draft that
incorporates these changes, instead of adopting the current draft and
then attempting to make these changes within the WG process. In
particular, these changes usefully reduce the scope to what is
generally understood to be safe and useful.