[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