Padding

[martinthomson]

Traffic analysis remains the biggest exposure with this design. Encryption and virtual CIDs help obscure the pattern of bits, but packet size and timing are harder to defend.

For packet size, it might be useful if there was a way to pad before encryption. However, padding will necessarily expand packets. Also, it would help if the padding were on a per-packet basis. As things approach MTU, the relative information they leak through size diminishes, but smaller packets can be highly identifying.

Padding would be applied by the client when sending to the proxy and by the proxy when forwarding to the client.

To indicate when padding is in use I think that we should look to steal one of the public bits in the first byte of the QUIC header. I see just a few options:

1. The short/long flag (0x80). This is available because we only ever set a value to 0. This would violate QUIC invariants, but ...... ¯\_( ͡° ͜ʖ ͡°)_/¯
2. The QUIC bit (0x40). This is available, but if we ever find another use for it this use might conflict with that use. We wouldn't be able to negotiate the use of this bit for other purposes (including grease) unless we were willing to do two-way trial decryption.
3. The spin bit (0x20). This is basically already in use, but we might conclude that not spinning the bit is OK for this application.

Once we have that bit, we can toggle it to indicate that there is padding. I would suggest that we pad at the end of the packet, so that we don't need to move packet contents around. Standard padding schemes are to include a run of zeros from the last octet, with padding ending on a non-zero octet (this is the TLS padding scheme). There are, of course, many equally-valid alternatives.

[tfpauly]

In a multi-hop proxy model, probably the best thing to do for packet size correlation mitigation is to have the connection between the client and the second proxy always send QUIC SH packets of known sizes (small / medium / large fixed sizes) such that the sizes are not interesting.

At that point, I don't think it is helpful for the first proxy to add any padding.

Essentially, my initial impression is that this a problem for the client-to-target (obviously assuming that the client and target can sufficiently coordinate).

[martinthomson]

That requires client-client coordination to be effective; whereas padding by the proxy does not. I realize that you might be less interested in that approach, but I don't see much harm in specifying it.