Re: [TLS] Large extensions in the ClientHello

Martin Rex <mrex@sap.com> Thu, 15 September 2011 00:56 UTC

Return-Path: <mrex@sap.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 98BAC21F8B68 for <tls@ietfa.amsl.com>; Wed, 14 Sep 2011 17:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.026
X-Spam-Level:
X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 gcKuCwGCaLF8 for <tls@ietfa.amsl.com>; Wed, 14 Sep 2011 17:56:26 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6321F8B67 for <tls@ietf.org>; Wed, 14 Sep 2011 17:56:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8F0wUae029280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 02:58:30 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201109150058.p8F0wTX7003865@fs4113.wdf.sap.corp>
To: agl@google.com
Date: Thu, 15 Sep 2011 02:58:29 +0200
In-Reply-To: <CAL9PXLxQKju-86mZWOWik76rAxT9GrPzPRaf-CNdv4T8mYzZUg@mail.gmail.com> from "Adam Langley" at Sep 13, 11 11:06:25 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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: Thu, 15 Sep 2011 00:56:26 -0000

Adam Langley wrote:
> 
> 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.)

A ClientHello extension of size 2**24-1 = 16 MBytes ?

There are likely numerous more pleasurable ways to commit suicide
than doing this.

Really, what is it that you're trying to accomplish?

There are so many problems that something like this will cause,
that it is likely better to use a totally different solution
(_not_ within the TLS handshake).

A large ClientHello is terrible for TCP congenstion control
(TCP slow start), the data is unavoidably in the clear,
the data not even integrity protected until after successful
completion of the TLS handshake, so the TLS stack has to
keep it around over a network round trip (once as TLS extension
data, and maybe a second time as a "cached handshake message"
in order to compute a handshake message hash with any possible
hash algorithm later during the TLS handshake.


-Martin