Re: [TLS] Large extensions in the ClientHello

Marsh Ray <marsh@extendedsubset.com> Tue, 13 September 2011 16:58 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80321F8B42 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 09:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfVnRxccHs2T for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 09:58:31 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 281AE21F8B2F for <tls@ietf.org>; Tue, 13 Sep 2011 09:58:31 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1R3WLd-000F2s-Do; Tue, 13 Sep 2011 17:00:37 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 56FE76067; Tue, 13 Sep 2011 17:00:35 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18A3DTZvPqAbTOafpzQsI85q0J3OWD6IX4=
Message-ID: <4E6F8C34.1080503@extendedsubset.com>
Date: Tue, 13 Sep 2011 12:00:36 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Florian Weimer <fweimer@bfk.de>
References: <82pqj4ij2f.fsf@mid.bfk.de>
In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Large extensions in the ClientHello
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 13 Sep 2011 16:58:31 -0000

On 09/13/2011 10:00 AM, Florian Weimer wrote:
> I need to fit up to 2**24-1 bytes into a ClientHello extension.  If I
> read the protocol language correctly, the limit is 2**16-1, for all
> extensions, and there is no way around that without major protocol
> changes.  Is this correct?

A big part of the reason this isn't in the current protocol is that it 
would be particularly susceptible to DoS. Receiving that much data is 
not free and it's usually not a good idea to have your server be willing 
to receive and process it from an unauthenticated source.

Still, you might be able to achieve the same semantics:

1. Exchange a small extension on the initial handshake to negotiate the 
use of the "jumbo extension". In that handshake propose one or more 
TLS_DH_anon cipher suites.

2. If the server chooses to accept the use of the jumbo extension in the 
ServerHello, he is coded to also accept one of your proposed TLS_DH_anon 
cipher suites and not transmit any server certs (nor request client auth).

3. The 2**24 - 1 bytes are sent from the client to the server as 
application data. Be certain that you have a crypto-quality record 
structure in this data so the server can determine where it ends without 
ambiguity.

4. When the server has received and processed all the data, he sends a 
'Hello Request' to the client. The client agrees to renegotiate the 
session with the server, both strictly requiring the use of the RFC 5746 
'Renegotiation Indication' extension. Yes, TLS renegotiation has gotten 
a bad name but RFC 5746 fixes all that. The client sends the small 
extension again on his Client Hello, perhaps with an indication that 
it's phase 2.

5a. If now after seeing the 2**24 - 1 bytes, the server agrees to the 
use of the jumbo extension, it replies with a confirming small extension 
on the Server Hello.

5b. If the server does not confirm the use of this extension, all prior 
state and buffered data is discarded by the client and server and this 
renegotiation handshake is treated exactly like an initial handshake 
(with the exception of the valid RI extension data) which declined the 
use of the extension.

Important considerations:

* Both client and server must be extra careful to ensure that a 
TLS_anon_DH cipher suites is never accepted for sessions that should not 
have them.

* Both client and server must be extra careful to require the successful 
negotiation of RFC 5746 RI.

* Anyone deploying such a scheme knows exactly what they're buying in 
terms of DoS exposure. You may have something in mind to address it.

* Middle boxes are likely to puke all over this. Even TLS stacks may 
need to be compiled specially to allow anon DH, (but it's a new 
extension anyway).

* Martin Rex (and others) will likely have some very thoughtful feedback 
on this scheme. :-)

- Marsh