Re: [TLS] Limited rollback attacks in False Start and Snap Start

Martin Rex <> Fri, 20 August 2010 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 023943A684C for <>; Thu, 19 Aug 2010 22:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.842
X-Spam-Status: No, score=-9.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PQEvVytY-jKr for <>; Thu, 19 Aug 2010 22:12:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E52E13A6820 for <>; Thu, 19 Aug 2010 22:12:56 -0700 (PDT)
Received: from by (26) with ESMTP id o7K5DSZX025088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Aug 2010 07:13:28 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
Date: Fri, 20 Aug 2010 07:13:27 +0200
In-Reply-To: <002a01cb3ff3$1d0a7ae0$571f70a0$> from "Brian Smith" at Aug 19, 10 06:06:04 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Subject: Re: [TLS] Limited rollback attacks in False Start and Snap Start
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: Fri, 20 Aug 2010 05:13:01 -0000

Brian Smith wrote:
> With current TLS, the client and server securely agree on how *all* the
> application data is encrypted. With False Start  the server no longer has
> any say in which cipher or which TLS version (in particular, TLS 1.0 vs. TLS
> 1.1 CBC handling) is used to protect the application data that the client
> sends, given an active MitM.

With False Start, the client is optimistic in checking the Server Cert
and starting to send encrypted Data.  The interesting thing about
False Start is, that the client may can be using this without the
server necessarily being aware of it. (No changes on the server
required, it probably just works if the client puts the app data
into a seperate SSL record as the ClientFinished message.

If the optimistic client is considered a problem, this could be
fixed with a slightly skewed TLS extension or with a new
Server->client Handshake message (enabled by a TLS extension.

Similar to the client signing previous handshake messsages,
when authenticating, the server could sign the client hello and
(most of) the server hello on the first round-trip.

If only a TLS extension is used, then it is a little skewed,
because the Server can only sign the ServerHello part without
the signature value itself, which is a little difficult
given how the hash of the handshake messages is normally created and
incorporated into a digital signature (e.g. CertificateVerify)

And the signature could not be verified while disassembling
ServerHello, the Client would have to read and process the
ServerCertificate handshake message before being able to
verify a digital signature over ClientHello and part of
ServerHello that travels in a TLS extension within ServerHello.

If only signallig (for a new Server-Client CertificateVerify
handshake message following ServerCertificate) would be done
with the TLS extension, then it might be more conventional
in-order processing of handshake messages and the handshake
message hash (and the server signature would then cover
the ServerCertificate handshake message as well).