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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
