Re: [TLS] Large extensions in the ClientHello

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 13 September 2011 16:12 UTC

Return-Path: <juhovh@iki.fi>
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 0350621F8BF3 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 09:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level:
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 5yTSXZ8Ew7Fa for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 09:12:12 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7821F8BEC for <tls@ietf.org>; Tue, 13 Sep 2011 09:12:12 -0700 (PDT)
Received: from mail.visino.fi (88.192.37.90) by jenni2.inet.fi (8.5.133) id 4DF73E85046C0255; Tue, 13 Sep 2011 19:14:16 +0300
Received: from [192.168.1.101] (dsl-hkibrasgw3-ff2cc000-252.dhcp.inet.fi [88.192.44.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 05EDE1FE85; Tue, 13 Sep 2011 19:14:14 +0300 (EEST)
References: <82pqj4ij2f.fsf@mid.bfk.de>
In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de>
Mime-Version: 1.0 (iPhone Mail 8L1)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <CA24A033-37C4-4177-AC9E-172FC3B0044E@iki.fi>
X-Mailer: iPhone Mail (8L1)
From: Juho Vähä-Herttua <juhovh@iki.fi>
Date: Tue, 13 Sep 2011 19:14:08 +0300
To: Florian Weimer <fweimer@bfk.de>
Cc: "tls@ietf.org" <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:12:13 -0000

On 13.9.2011, at 18.00, Florian Weimer <fweimer@bfk.de> 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?

Yes, the length limit for all extensions combined together in ClientHello is 2^16-1 and there's no easy way aroud that as far as I can see. In theory I guess one could add some more data after the extensions in versions up to TLS 1.1, but TLS 1.2 explicitly forbids that as well, and I'm not sure if it would result in problems in interoperability anyway.

More proper way for you to send over 2^16-1 bytes of data would be to define a short extension for negotiating your intended use and also define a new handshake message you can send to server after receiving ServerHelloDone, if the server indicated it supports your extension. This doesn't work of course if you need that large chunk of data _before_ sending ServerHello, but I wonder what would be the use case there. Maybe you can shed some light on that.

> 

Juho