Re: [TLS] Interaction between cookies and middlebox compat mode

[Ilari Liusvaara <[e-mail]>]

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