Re: [TLS] Large extensions in the ClientHello

Adam Langley <agl@google.com> Tue, 13 September 2011 15:04 UTC

Return-Path: <agl@google.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 231AC21F8B2C for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 08:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 KUZy0z+UzUF4 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2011 08:04:21 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4F721F8B24 for <tls@ietf.org>; Tue, 13 Sep 2011 08:04:21 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p8DF6Rrm011257 for <tls@ietf.org>; Tue, 13 Sep 2011 08:06:27 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315926387; bh=XhOsYibeWd0cQovMYiXLP+buogQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=R2iVKuWL35veUs4ZmTSCrOLO1jIo9yC3G8MwEh/U76JgBU+GXmekngLLSdiZcsuL/ pKAvPKmi4ZAHllek/f2sg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=SjZkFn4akuXzSFLLnhV8vGQdlV8BG20imAoQICHjjnXjESlnVzRuiTIg5vU4aTRI2 uIGbZjfqx6WFPr2dkXKgg==
Received: from yih10 (yih10.prod.google.com [10.243.66.202]) by wpaz17.hot.corp.google.com with ESMTP id p8DF6PfC019848 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Tue, 13 Sep 2011 08:06:26 -0700
Received: by yih10 with SMTP id 10so626279yih.7 for <tls@ietf.org>; Tue, 13 Sep 2011 08:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LAWpybOxyFznyy1dcmC1S4rKG4wNDVVg9jL5d7NT0lM=; b=EAEzgzkNiM87V2Bqs5YUCfWHZoeWqDMN8WJqQnRgWiJ+atOkEYAoJMu6Lni/SxnKHr 4sBVLFW+edJ/NWtunDCg==
Received: by 10.42.29.8 with SMTP id p8mr579027icc.157.1315926385629; Tue, 13 Sep 2011 08:06:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.29.8 with SMTP id p8mr579022icc.157.1315926385443; Tue, 13 Sep 2011 08:06:25 -0700 (PDT)
Received: by 10.231.19.137 with HTTP; Tue, 13 Sep 2011 08:06:25 -0700 (PDT)
In-Reply-To: <82pqj4ij2f.fsf@mid.bfk.de>
References: <82pqj4ij2f.fsf@mid.bfk.de>
Date: Tue, 13 Sep 2011 11:06:25 -0400
Message-ID: <CAL9PXLxQKju-86mZWOWik76rAxT9GrPzPRaf-CNdv4T8mYzZUg@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Florian Weimer <fweimer@bfk.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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 15:04:22 -0000

On Tue, Sep 13, 2011 at 11:00 AM, 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?

That's correct. At best I think you could use a small extension to
negotiate and then have the client send it's jumbo handshake message
as a new handshake type.

(Although keep in mind that some TLS implementations will reject
handshake messages are are split over multiple records, although
hopefully any that negotiate your extension will have sorted that
out.)


Cheers

AGL