On Thu, Dec 28, 2017 at 04:12:52PM +0000, Matt Caswell wrote: > > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers.
Stateless servers also have the problem of dealing with nasty things like fragmented ClientHello messages (yuck) or other initial fragmented messages (which should not happen outside attacks). And unlike DTLS where one can detect subsequent fragments of message, this is not possible in TLS. And since one can not commit state for each connection, the mitigations are much more limited. I suppose one way of handing things is to send a fatal-level unexpected_message alert (of course without tearing connection down, since there is nothing to tear down) in response to any handshake record that does not start with 0x01 byte unless there is pending reassembly state or connection state. The reassembly states would be limited in number (possibly to 0) and and size to avoid DoS. What alert to use if the message is too large to reassemble (if there are 0 reassembly states, any message is too big to reassemble)? Lower-layer reassembly might be possibility. That doesn't allow ClientHello messages larger than 16kB, but that would be give considerably more freedom with Post-Quantum key exchanges than <1232 bytes one gets with single packets[1]. I think QUIC does not support any kind of reassembly of Client Hello. [1] NIST PQC Round1 has only 3 candidates (LAKE, Round2 and SIKE) that have triple digits public key sizes at "level 3 security" below 800 bytes (in fact, all three are somewhere between 500 and 600 bytes). Those are pretty aggressive (or slow in case of SIKE), and the sizes might grow quite a bit as new attacks are discovered. With 3kB space for public keys, there would be considerably more candidates (and space for parameter adjustments). These include even ~20 year old schemes like NTRU (which is one of the candidates). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
