[TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt

Bodo Moeller <bmoeller@acm.org> Thu, 07 May 2015 15:24 UTC

Return-Path: <bmoeller@acm.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 692221A92BA for <tls@ietfa.amsl.com>; Thu, 7 May 2015 08:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.038
X-Spam-Level: **
X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JjkBBOEe9lDi for <tls@ietfa.amsl.com>; Thu, 7 May 2015 08:24:36 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870971A92BB for <tls@ietf.org>; Thu, 7 May 2015 08:24:34 -0700 (PDT)
Received: from mail-lb0-f177.google.com ([]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0MORwj-1Yvcqz3V2r-005qVQ for <tls@ietf.org>; Thu, 07 May 2015 17:24:32 +0200
Received: by lbbqq2 with SMTP id qq2so33631177lbb.3 for <tls@ietf.org>; Thu, 07 May 2015 08:24:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id cr4mr3613497lad.56.1431012272035; Thu, 07 May 2015 08:24:32 -0700 (PDT)
Received: by with HTTP; Thu, 7 May 2015 08:24:31 -0700 (PDT)
In-Reply-To: <20150506101230.32573.26774.idtracker@ietfa.amsl.com>
References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com>
Date: Thu, 7 May 2015 17:24:31 +0200
Message-ID: <CADMpkcLzW-ci5ZVocQ-Tz9vS6-ngM5vb_0E1P0SZS-obdAZDRw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11348c3824e16705157f829d
X-Provags-ID: V03:K0:bS9Pa2Jke/dquELivY+GUiZU1ey69riQdcmS6XQA7FvZMOxaRjp j062SH7rYz4xJuS424mklCtK1EZvyI1HMa1wZq39ow4eX7FGrGIs6OGcqAznL665c/Um22Y 1++Ds+KVSuebXjOHFnMIpPkM+D5Eq+ADjgFzv7G/4rCTWOo6tqJbnOKC8HilGETvbjGah1C KAVvKtQzhiPcC1eLZ3SFA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mbFbDI7LwQHmPxOeyRX6ooOd8T0>
Subject: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt
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: Thu, 07 May 2015 15:24:38 -0000

As discussed with Sean, draft-ieft-tls-falsestart-00 intentionally is
essentially a copy of draft-bmoeller-tls-falsestart-01 (with only metadata
updated), not because we don't want to make changes but because we want to
start doing these between -00 to -01 for ease of tracking.

I intend to change the following (and then expect new comments on the
updated I-D resulting in a -02 revision):

- The intended status should probably be "Informational".

- Be clear that the document does not apply to TLS 1.3 and beyond, because
these protocols come with new protocol flows designed to reduce the number
of round-trip times.

- Remove server-side False Start entirely, as the document (now) is mainly
about describing existing deployments. (Server-side False Start isn't
entirely pointless, but I don't think anyone ever saw a sufficiently
compelling case for it to actually deploy it.)

- State explicitly that for client implementations with a maximum version
of TLS 1.2, normally the protocol version whitelist should be TLS 1.2 only
(but clients that don't support TLS 1.2 may be using False Start with
earlier protocol versions, and clients that support TLS 1.3 might disable
False Start entirely -- that's what the TLS_FALLBACK_SCSV language is
really about).

- Recommend against use of False Start with (EC)DHE on any kind of explicit
groups, and on named groups of insufficient size. (I don't think we should
try to predict whether the ffdhe groups from
draft-ietf-tls-negotiated-ff-dhe-08 will catch on with TLS 1.2, so False
Start with traditional DHE shouldn't be entirely left out.)

Then Brian had a comment about False Start with client certificates. I'm
not yet sure what to make out of that. The main point of mentioning client
certificate types in the I-D was to make sure that False Start isn't used
with rsa_fixed_dh and the like (since client implementations might allow
mixing client-side static DH with server-side ephemeral DH, assuming they
support DH certs at all). Sending client certs in the clear may not be a
good idea, but that issue seems entirely orthogonal to what False Start is
all about. Do you see an actual problem about sending a client's signing
cert specifically in a False Start handshake?


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2015-05-06 12:12 GMT+02:00
Subject: New Version Notification for draft-ieft-tls-falsestart-00.txt
To: Adam Langley <agl@google.com>om>, Bodo Moeller <bmoeller@acm.org>rg>,
Nagendra Modadugu <nagendra@cs.stanford.edu>du>, Nagendra Modadugu <

A new version of I-D, draft-ieft-tls-falsestart-00.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Name:           draft-ieft-tls-falsestart
Revision:       00
Title:          Transport Layer Security (TLS) False Start
Document date:  2015-05-06
Group:          Individual Submission
Pages:          11
Status:         https://datatracker.ietf.org/doc/draft-ieft-tls-falsestart/
Htmlized:       https://tools.ietf.org/html/draft-ieft-tls-falsestart-00

   This document specifies an optional behavior of TLS implementations,
   dubbed False Start.  It affects only protocol timing, not on-the-wire
   protocol data, and can be implemented unilaterally.  The TLS False
   Start feature leads to a latency reduction of one round trip for
   certain handshakes.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat