Subject: [TLS] Large extensions in the ClientHello

From: Florian Weimer <[email-masked]>
Date: Tue, 13 Sep 2011 15:00:08 +0000

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?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Sep 2011 11:06:25 -0400

> 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

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 13 Sep 2011 19:14:08 +0300

> 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

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Sep 2011 12:00:36 -0500

> 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

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Sep 2011 02:58:29 +0200 (MEST)

Adam Langley wrote:
> > I need to fit up to 2**24-1 bytes into a ClientHello extension. Â If I

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