Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

Marsh Ray <> Wed, 02 June 2010 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F391228B797 for <>; Wed, 2 Jun 2010 11:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5+mtZapkNmeP for <>; Wed, 2 Jun 2010 11:55:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C53EA3A683F for <>; Wed, 2 Jun 2010 11:55:59 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OJt6J-000A0d-Jc for; Wed, 02 Jun 2010 18:55:41 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id CF86564D8 for <>; Wed, 2 Jun 2010 18:55:35 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19UEfZErt8Z70O1q3o8OTu/NQpQn8KN6kw=
Message-ID: <>
Date: Wed, 02 Jun 2010 13:55:31 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jun 2010 18:56:01 -0000

My first reactions are:

1. This proposal scares me. Wasn't the Finished message added in
response to vulnerabilities in SSLv2? Doesn't this sort of, umm, undo
that for initial data from the client? It bears repeating that in TLS
usage for a secure web application that first transmission from the
client to the server would be expected to contain the session cookie,
perhaps even the full plaintext credentials for a form-based login. The
entire security model of web apps is based on the inability of the
attacker to decrypt this.

2. Couldn't a similar optimization be achieved without protocol changes
by simply implementing session resumption more robustly? Session
resumption also takes things like cert chain validation and revocation
checking out of the critical path of the handshake but this proposal
still depends on it.

3. This is an interesting idea and you guys have clearly thought this
through. I am suspicious, I can't find an exploitable bug in it (yet).

On 6/2/2010 10:47 AM, Adam Langley wrote:
> On Wed, Jun 2, 2010 at 11:19 AM, Martin Rex <> wrote:
>> In those application architectures, where the client app authentication
>> is _not_ performed through a callback, but instead in a synchronous
>> fashion after completion of the TLS handshake, TLS False Start will
>> likely not be possible.
> Certainly the design of some TLS code might make False Start awkward
> or impossible. In those cases, it need not be supported.

Last I checked this included IE, Chrome, and everyone else that used
Schannel on MS Windows.

The vast majority of tutorial/example code availiable on the web has the
application check the name on the certificate (those rules are protocol
specific after all) only after the TLS stack has returned with a
successful handshake. So this would require API and client application
changes and could not be enabled by default.

>> And I think that a client should _not_ try TLS False Start with
>> a Server that lacks TLS Renegotiation Extension support (rfc5746).
> I'm afraid that I don't see where the considerations of talking to a
> server without the renegotiation extension, and using False Start,
> interact. I think they are independent.
> If an attacker were conducting a renegotiation attack, and altered the
> handshake in any way (say, to remove a renegotiation extension), then
> the client's Finished message would be rejected by the server.

But the server's Finished message will not have been validated by the
client, so the security analysis for the RI fix must start over with the
expectation that the client cannot trust the presence or absence of an
RI extension. If the client didn't ever have to trust it, then why did
we send it in the server-to-client direction anyway?

AFAICT, RI is the only TLS extension that's presence is mandatory for
security purposes. But other extensions affect the handshake somehow or
else they wouldn't be sent, and how much of TLS really doesn't affect
security somehow? E.g. SNI? Seems like everything must be re-analyzed
from scratch if we are to be safe sending confidential data before fully
validating the server.

- Marsh