[TLS] Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.txt)

The IESG <iesg-secretary@ietf.org> Mon, 23 May 2016 16:34 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160523163413.20947.52104.idtracker@ietfa.amsl.com>
Date: Mon, 23 May 2016 09:34:13 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LL_tjRK5EGtYc4P8T0RpbsYV4p8>
Cc: tls@ietf.org, tls-chairs@ietf.org, draft-ietf-tls-falsestart@ietf.org, The IESG <iesg@ietf.org>, rfc-editor@rfc-editor.org
Subject: [TLS] Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.txt)

The IESG has approved the following document:
- 'Transport Layer Security (TLS) False Start'
(draft-ietf-tls-falsestart-02.txt) as Informational RFC

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/

1. Summary

"False Startâ was an attempt to reduce the latency impact of HTTPS based on the simple premise that the client send application data earlier in the handshake; to be precise clients send application data before they have received and verified the server's "Finishedâ message. Initial measurements showed a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the implications at the end of s2.

Note that this âexperimentâ was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some additional details:

- Chrome 20 disable it except for sites that enabled NPN.

- Firefox has (or at some point had) an NPN requirement to enable False Start.

- Safari as an additional example without the NPN requirement:
http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslTransport.c

- While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official release.

As far as where you should point your fingers:
- Sean Turner is the document shepherd, and;
- Stephen Farrell is the responsible Area Director.

2. Review and Consensus

There wasnât a whole lot of discussion, primarily because "False Startâ the implementation issues were worked out by the browsers and the WG didnât adopt this draft until long after (Nov-2014). The draft was adopted because it documents existing practices and provides security considerations [0]; the comments in the WG adoption thread were incorporated in the -01 WG version. The WGâs deliberations resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3).

One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade protections defined in [1] are in adequate. To solve address this issue, the âFalse Startâ draft requires whitelists as well as large groups/curves.

[0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

RFC Editor Note

Please change the intended status in the header to "Informational"
I don't believe any other text changes are needed. (The IESG and
authors figured that informational was better during IESG eval.)

[TLS] Document Action: 'Transport Layer Security … The IESG