[openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected

[Matt Caswell]

On 25/09/15 20:19, Kurt Roeckx wrote:
> On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
>>
>> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends 
>> up as an extension, possibly multiple ones), and that quantum computing 
>> resistant algorithms usually require fairly large key sizes (large 
>> enough that protocol limitations itself are problematic), we may see 
>> Client Hellos larger than 16k in not so far future.
> 
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.

If the ClientHello message is longer than 131396 bytes then either we
are under some kind attack, or it is in some future format that we do
not understand and is not backwards compatible (a requirement of
backwards compatibility would be that it is under or equal to that
limit). Either way we should drop the message.

My concern is whether we should have a limit that is less than that. A
default s_client ClientHello on master at the moment is 364 bytes. A
default ClientHello with a ticket is 556 bytes. The biggest ClientHello
I can induce from s_client is one including a ticket and a cipher string
of "ALL:@SECLEVEL=0" which leads to 618 bytes. I recognise that we are
talking about future proofing; but the current limit of 16384 already
gives us the ability to accept ClientHello's 26 times bigger than the
biggest s_client can create today. That is significant room for future
growth.

On the other side of the coin handling very large ClientHello's is not
without cost and risk. There is bandwidth consumption, memory
consumption, CPU consumption handling any operations required from the
ClientHello (e.g. decrypting an enormous SessionTicket) etc. We also
have to bear in mind the OpenSSL doesn't necessarily just run on big
powerful servers in datacentres. It can also runs in very resource
constrained environments. We potentially open up our users to DoS
attacks by attempting to accept these "godzillagram" (as someone called
them) ClientHellos. Right now, today, if a server starts receiving
ClientHello's that big then it is almost certainly an attack. Increasing
the maximum size over what we have today increases the risk of attacks
right now.

Of course we don't know what the future will bring. I'm struggling to
foresee a scenario where we have a vast explosion in the ciphersuites
available (which is where a significant proportion of the "allowed"
ClientHello size is allocated) - but I guess it could happen. Possibly
more likely is some new extension(s) requiring very large extension data
blocks. Still, whatever that extension is, it would have to be
*massively* bigger than any extension we have today to blow the existing
limit - and absolutely HUGE to go anywhere near 131396. The latency
costs of managing such large ClientHello's would be significant so I am
really finding it hard to see a future where ClientHello's get even
close to approaching the kind of sizes we're talking about. So why would
we open up our users today to increased risks for a future that seems
quite unlikely?

So, what I'm trying to say is it's a balancing act. We shouldn't just
accept the biggest possible messages that we can just because that gives
us the best interoperability for the future. There are other
considerations.

Matt