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

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

MIME-Version: 1.0
In-Reply-To: <20150506101230.32573.26774.idtracker@ietfa.amsl.com>
References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com>
Date: Thu, 07 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"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mbFbDI7LwQHmPxOeyRX6ooOd8T0>
Subject: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt
Precedence: list

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?

Bodo



---------- 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>, Bodo Moeller <bmoeller@acm.org>,
Nagendra Modadugu <nagendra@cs.stanford.edu>, Nagendra Modadugu <
Nagendra@cs.stanford.edu>



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
URL:
https://www.ietf.org/internet-drafts/draft-ieft-tls-falsestart-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ieft-tls-falsestart/
Htmlized:       https://tools.ietf.org/html/draft-ieft-tls-falsestart-00


Abstract:
   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

[TLS] Fwd: New Version Notification for draft-ief… Bodo Moeller
Re: [TLS] New Version Notification for draft-ieft… Bodo Moeller
Re: [TLS] Fwd: New Version Notification for draft… Martin Thomson
Re: [TLS] Fwd: New Version Notification for draft… Brian Smith
Re: [TLS] Fwd: New Version Notification for draft… Brian Smith