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

From: Sean Turner <[email-masked]>
Date: Tue, 31 Mar 2015 12:20:00 -0400

All,

There’s been some interested expressed in having http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ 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.

J&S

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Mar 2015 16:21:28 +0000

> 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.

+1

---

From: Sean Turner <[email-masked]>
Date: Tue, 31 Mar 2015 12:34:26 -0400

I also meant to add please let us know by 2015-04-14.

spt

On Mar 31, 2015, at 12:20, Sean Turner <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2015 10:27:24 -0700

> There’s been some interested expressed in having http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted as a TLS WG item.  If you would like for this draft to become a WG document,…

If the adopted draft becomes clearer that it is for TLS 1.2 (and possibly 1.1) only, but not for 1.3 (since we don't know what that will look like), I support its adoption.

--Paul Hoffman

---

From: Andrei Popov <[email-masked]>
Date: Tue, 31 Mar 2015 17:52:36 +0000

The draft is useful in that it documents existing practice and provides security considerations. I support adoption.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Tuesday, March 31, 2015 9:34 AM
To: <[email-masked]>
Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart

spt

On Mar 31, 2015, at 12:20, Sean Turner <[email-masked]> wrote:

> All,
> 
> There's been some interested expressed in having http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ 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.
> 
> J&S

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 10:53:50 -0700

> The draft is useful in that it documents existing practice and provides security considerations. I support adoption.

What Andrei said.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 31 Mar 2015 14:29:27 -0400

On Tue 2015-03-31 12:20:00 -0400, Sean Turner wrote:

> There’s been some interested expressed in having
> http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ 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 working group adoption of this draft, since it documents
existing practice and addresses a common concern about reducing latency.

  --dkg

---

From: Brian Smith <[email-masked]>
Date: Tue, 31 Mar 2015 16:33:37 -1000

> There’s been some interested expressed in having http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted as a TLS WG item.  If you would like for this draft to become a WG document,…

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.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=861310
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=952863
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1109766
[4] https://code.google.com/p/chromium/issues/detail?id=427721