Re: [secdir] Secdir review of draft-ietf-tls-falsestart-01

Bodo Moeller <> Wed, 11 May 2016 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D419F12D5DE for <>; Wed, 11 May 2016 14:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjCKoXKvOfXI for <>; Wed, 11 May 2016 14:28:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9636512D5E4 for <>; Wed, 11 May 2016 14:28:45 -0700 (PDT)
Received: from ([]) by (mreue004) with ESMTPSA (Nemesis) id 0McRue-1bIH5n1hq4-00HgvK for <>; Wed, 11 May 2016 23:28:43 +0200
Received: by with SMTP id n11so1913865lbh.1 for <>; Wed, 11 May 2016 14:28:43 -0700 (PDT)
X-Gm-Message-State: AOPr4FVpwqdKWqYzcuvEa6yOm2Tkk4yQTCdpJDtv21Jv2AC1qNa8BFWxIbBsTFdDw9mG1klcfSMmmNfyM5abfA==
MIME-Version: 1.0
X-Received: by with SMTP id ao9mr2272933lbc.38.1463002122734; Wed, 11 May 2016 14:28:42 -0700 (PDT)
Received: by with HTTP; Wed, 11 May 2016 14:28:42 -0700 (PDT)
Date: Wed, 11 May 2016 14:28:42 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
From: Bodo Moeller <>
To: secdir <>
Content-Type: multipart/alternative; boundary=001a11c36bdcd4db62053297b973
X-Provags-ID: V03:K0:G/jB6Z3t9snbKbFPJ9b8RjNFi7DA12P/oK8f6iYF4lt9rw4gBop vb/LeIuYOVA5Bg4+nZCqKmuiwsZ0F5tW7TFxtmnr15A1VhcWmbs5NlIXMl6OuMQi5NQkYza DeEy9PfBNCiNuPdMQINLX7K3G1sIiUNhlb6O/xvchKCN+PsbRx2IcK15HHyYqPYL5cDz7Di Pmjn6FXWsWqSNgaXq4jYg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aQvABFK1ZHc=:k+ObKoiMhpbJDJfzjL1oXD 67x9i7ocNQAx47BSlKaI0akhDsbstToP54uV1UoofxBjVpBmO7i3fiB0N0DE8qJvFMZee7bA9 awpZNcNMF2DHE/lfg/j6XbA8yI2g2owY8tIqDL/x9OkErf/iARsrk3Qpv+1RZvFag0Y8tbX1P TGIiYmSmuqZLtUOOLUNXtJbeua8qvWTeWCied3rP3nXurvvKXI3vyJRLhSPLr/Ot1Mae9F4hr Jvdf4ksYhlgIqxlS4I5z0fhRSYDMbIggzf50G4RgEoB8WpYsU4fe2+Vbu3+KEH7WbsSUFUtr1 79/qNN2LiZvhi0C3cxFdR8iauoPl8e9s8/RgpfdVU5KqSE12mpvdH/zuWXIeSwJeVs8TvOqSC lnR7vg97KotZirE21QYNhLdTPo0FrOUOtigtuUu+B9YmCm83ZTm0yG7N6nYo7qhP13ZzLaVIz DqagMuGJL8Z5cGPKHzagknv1KRKhEqy2w5lc5Z+nuSFGxEe+65y7dTT2n+FZ0J6dlf4UIc1Eo VwM0tcB/dAOEiUigSAa+W/mTwBLZVnAmZM0D5gKFru+E/TyD7ndE3HU67L9opOkUsOOUeqNQk xJ5+aRW36lCnUNHF5IvX4sqHEMECaV1ztvSb16z5Gk20Vr2R9IYXArRibpRj/wNmOs85N499L XhFT/I10kaYlu3jQvDJG88sz6r3hg5Aty0Jtk0O/PKeqdUkfXu6TzL73vrzVBXlY3LAAy8dK3 nVZjcQPjMSWWy607
Archived-At: <>
Cc: Nagendra Modadugu <>, Adam Langley <>
Subject: Re: [secdir] Secdir review of draft-ietf-tls-falsestart-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 May 2016 21:28:51 -0000


thanks for your comments.

Some nits:

Section 3 talks about determining whether a TLS server is "false start
> compatible". I believe any server that correctly implements TLS (i.e.,
> following the specification) would be false start compatible. That does not
> imply that all would be, and it would be useful to do some testing to see
> whether most implementations in fact are. Publishing this as an
> experimental RFC is likely to encourage such an effort.

I'm truly not sure about this. By the TLS specification, servers wouldn't
have to expect early handshake messages, so arguably server behavior in
their presence is left unspecified -- however, I'd certainly not be
surprised if all server implementations that aren't false start compatible
are indeed strictly broken (I see no good reasons for TLS servers to *not*
tolerate handshake messages that arrive early).

In any case, I think the concept of a TLS server being "false start
compatible" is useful, so don't think I'd want to make a change to the
document there.

Section 2 paragraph 1 says that TLS requires two full protocol rounds
> before the handshake is complete. While technically this is true, it
> overstates the benefit of this enhancement because TLS rides atop TCP which
> has its own protocol round before it starts carrying application payloads.
> So this enhancement reduces that TLS startup time from three round trips to
> two rather than the more dramatic two to one.

I don't really agree that draft-ietf-tls-falsestart-01 overstates the
benefit, it's just that the round-trip time added by TCP is mostly an
orthogonal issue: RFC7413 (TCP Fast Open) addresses it. I'll discuss that
point and mention that RFC in draft-ietf-tls-falsestart-02.