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

"Brian Smith" <brian@briansmith.org> Thu, 19 August 2010 23:05 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5F63A6A00 for <tls@core3.amsl.com>; Thu, 19 Aug 2010 16:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvFFf7wGt+fO for <tls@core3.amsl.com>; Thu, 19 Aug 2010 16:05:37 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id C7C623A69F5 for <tls@ietf.org>; Thu, 19 Aug 2010 16:05:37 -0700 (PDT)
Received: from T60 (unknown [98.200.150.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B6EF0509DD; Thu, 19 Aug 2010 19:06:11 -0400 (EDT)
From: "Brian Smith" <brian@briansmith.org>
To: <tls@ietf.org>
Date: Thu, 19 Aug 2010 18:06:04 -0500
Message-ID: <002a01cb3ff3$1d0a7ae0$571f70a0$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH56xbgHwXrPnLQnEvx7FjC4ctAfA==
Content-Language: en-us
x-cr-hashedpuzzle: AO/G CgBa ETUR E9Gz Fj3c HDxF KKK5 OJoQ W167 Xk/s ZymZ Z2/I bD5v dvia gDN2 gFbt; 3; YQBnAGwAQABnAG8AbwBnAGwAZQAuAGMAbwBtADsAYgBtAG8AZQBsAGwAZQByAEAAYQBjAG0ALgBvAHIAZwA7AHQAbABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {659A485F-6049-46C8-964A-FC1CD12BA3D5}; YgByAGkAYQBuAEAAYgByAGkAYQBuAHMAbQBpAHQAaAAuAG8AcgBnAA==; Thu, 19 Aug 2010 23:05:52 GMT; TABpAG0AaQB0AGUAZAAgAHIAbwBsAGwAYgBhAGMAawAgAGEAdAB0AGEAYwBrAHMAIABpAG4AIABGAGEAbABzAGUAIABTAHQAYQByAHQAIABhAG4AZAAgAFMAbgBhAHAAIABTAHQAYQByAHQA
x-cr-puzzleid: {659A485F-6049-46C8-964A-FC1CD12BA3D5}
Subject: [TLS] Limited rollback attacks in False Start and Snap Start
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Aug 2010 23:05:39 -0000

http://tools.ietf.org/html/draft-agl-tls-snapstart-00
https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

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. Similar considerations apply to Snap Start when
considering a servers' cipher suite preferences changing over time (between
connections) and considering that Snap Start doesn't specify how the client
chooses which algorithms to use. Note also that neither proposal provides a
mechanism for the server to securely indicate to the client that such
extensions should not be used, and a server cannot find out that the
extensions are in use until after the client has already sent application
data encrypted with the MitM-influenced TLS version and cipher.

With the current TLS standards, in the event of a break in any symmetric key
cipher, a TLS server would have been able to prevent all exploits of that
break for new TLS connections simply by disabling the cipher suites on the
server side. This is no longer an effective countermeasure given clients
that implement these proposals; instead, all implementations of these
proposals have to be modified and/or reconfigured.

Currently implementations of False Start (Google Chrome and soon Mozilla
Firefox 4) allow any protocol version 3.0+, and any cipher suite the user
has enabled with key size of at least 80 bits. A quick check indicates that
this includes RC2-128 (only in Firefox, disabled by default), RC4-128,
3DES-EDE, AES-128, AES-256, CAMELLIA (only in Firefox), and SEED (only in
Firefox). Note also that there many servers that already don't want RC2-128
and RC4-128 to be used already due to real and perceived weaknesses in those
algorithms.

Both proposals could be strengthened to be similar to standard TLS by only
allowing the client to use them after the client has received a signed
message from the server that (a) lists allowed cipher suites, (b) indicates
which of these optimizations the server allows, and (c) provides a time
limit on the usage of this information. Such a message would be similar to
the SMIMEEncryptionKeyPreference X.509 attribute, but mandatory instead of
optional, and preferably would exist outside of the certificate so that
standard certificates could be used. Also note that such a mechanism is
needed in order for Snap Start to be extended for key exchange methods other
than RSA key exchange anyway, in order to transmit the reusable (ECDH) keys.

Regards,
Brian