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

[Brian Smith <[e-mail]>]

Sean Turner <[e-mail]> 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 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