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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34DBD12D1A8; Wed, 11 May 2016 14:35:35 -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 D4byt-wsZeWk; Wed, 11 May 2016 14:35:33 -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 2B27C12D141; Wed, 11 May 2016 14:35:33 -0700 (PDT)
Received: from ([]) by (mreue001) with ESMTPSA (Nemesis) id 0MEwBu-1ap3Kj0SNu-00G0I7; Wed, 11 May 2016 23:35:31 +0200
Received: by with SMTP id j8so61328925lfd.2; Wed, 11 May 2016 14:35:30 -0700 (PDT)
X-Gm-Message-State: AOPr4FV/PLqKUkfAJFuEAwq9o/qJ69atRj4S9++PpnrNMDLpTk8xEsLcGyixiOY9XhnSJYZRzPwWMNj6lEfWeg==
MIME-Version: 1.0
X-Received: by with SMTP id e124mr2637948lfg.41.1463002530148; Wed, 11 May 2016 14:35:30 -0700 (PDT)
Received: by with HTTP; Wed, 11 May 2016 14:35:30 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 11 May 2016 14:35:30 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
From: Bodo Moeller <>
To: Charlie Kaufman <>
Content-Type: multipart/alternative; boundary=001a11411f9e1d7d08053297d2dc
X-Provags-ID: V03:K0:TzpqV+gK8JmZJaj+M14nkhlEwbVudOgxgZubbaoGeEsuPKGczIK b8Y/MCtLm7xVL8QXb+4zKPyGQs8gWNJIyk7MEn7EFMLrrCf/VWz2IuSiDshlnnde3JLlFVp K6grpto+x6xkHXqnIiRkXNZomdU5i6h1S4ZrZbIzDvCCLVCYjiJ5s4KTr4GqlxMOiFq+act 14Wrm+tciljWdXHByT+iA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:SnX0lT5JKwM=:AqYbUg2/3iKgnqdHtdMBQ8 Y/bfipnXaD64/1jL8RhGIkeYUy06u42XPUU1HYblrdGN6GuoYSMMCRM7rmAeINJhVdFjdZ2aJ Sm4NP7/nL8ieWZe0mcf9oRG8v+FraS+4vchPkEN2IVcJ/76az3PVQ2I8quGBUc4Kiq8cSTDoB VqL72Uoy309ZzaOQOFluPIa3t3dYTU1H5LLuZTST1x9KEShEf6kV5hB1xOQPxQe3OoRR+cUWI 48Z8JnE1tp80a5EfX8kxU7qrVkOBVbPvR85xkiDM+JoxOHf6OgtOhld06UNfvjC/ZtxQWx0Ps 0Mpl4uNIzVexC4jA3A6gBVkDa/1z2d7RuMalbfFUH9onErGWB6/eZdu3z9oPec8XF0Yjm4o3Q 1sJYeEtSUDKX3or6tMfOCSXK9UHaVv7/is7PJtBTn3ueuDAkPNJn96KfDucYqdApb0Y5lYdK3 fQ0YIvYJoeKwfpZbySXdTsKxlnX2fYvSTWy6Hfla2W0/TZDtGrkiUGZpTCfFHuW1bSpy4pRar BxeEYOIU2wsxz0NrVV1FpXTBGhMRnx/v/Zu0R1vX5LAWFZVvIuyoAjH0KzehHEPgmlPPfKxZi 4XzQNcUyi0ou/IUBUz0ICWEZK6VlELc/Ck4Fa2XjyC5F9usDRky6yqN4Cyh8JUDdWMW9aleeY tZT8T+AASHAK2ouDQ7GcT+a7wo3a8RE3wd3M/T2mjyHVU+sMoTY6mwTTfeR80tSK+HCwm/Izt LQ4kaEfytDcCuRxV
Archived-At: <>
Cc: "" <>, The IESG <>, "" <>
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:35:35 -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.


[Sorry if this is the second copy of this message that you receive, I
realized I'd previously dropped some of the CC recipients.]