Re: Payload length 0

[Christian Huitema <[e-mail]>]

On 5/20/2018 12:14 AM, Martin Thomson wrote:

> It only works to ensure that the last packet remains the last packet.  That
> doesn't seem like an actual defense against splitting.

I have been thinking of the middle-box hacks that could interfere with
packet coalescing, trying to build a threat model. I am not sure I can't
come with convincing attacks, or rather with convincing attacks that we
can defend against. For me the main coalescing scenarios are:

1) Client Initial (Client Hello) + 0Rtt.

2) Server Handshake (first flight) + 1Rtt.

3) Client Handshake (second flight) + 1Rtt

What would be the motivation for splitting? In the CI+0-RTT case, the
middlebox designer might have heard that 0Rtt is insecure, and might
sell blocking 0RTT as a feature. It might want to pass the CI and block
the 0Rtt. This can be done in many ways. Flipping a couple bits in the
0Rtt payload would achieve that -- decryption would fail, and the 0Rtt
will be ignored. Or, unwrap the coalesced packet, decrypt the CI using
the well known key, add padding to reach the min size, and reencrypt
using the well known key. Tweaking the long header is not going to fix
either of these hacks.

In the Server Handshake + 1Rtt case, the motivation might be similar:
prevent 0.5Rtt transmission because it is arguably insecure. Again, this
can be achieved by flipping bits in the 1Rtt payload to cause a
decryption error, or unwrapping and reformatting the handshake packet.
Since the handshake is only "protected" by a well known key, this is
still possible, even if we added some kind of coalescing indication in
the short header of the 1Rtt data.

In the Client Handshake + 1Rtt case, I fail to find a motivation. But
evil middlebox designers could invent something. Again, if the goal is
to remove the 1Rtt packet, tweaking the headers of that packet won't help.

If we did want to remove the attack, we would have to protect the
coalescing indication with a key that is unknown to the middlebox. That
probably requires an encrypted extension to the client hello, server
hello or finished messages. we could do that, but I wonder whether
that's worth the effort.

-- Christian Huitema