Proof of receipt of packets in ACK

[ekr]

The "skip a packet number" thing as a defense against ack spoofing is kinda hacky and seems like it is going to make life difficult for us if we want to do other stuff with packet numbers. As a concrete example, if we want to use server-issued PN tokens, then the server doesn't know what you're going to skip as a client. In addition, it's a different mode the sender has to be in.

I suggest a simpler design: every ACK frame contains a 32-bit field containing the XOR of the final 4 bytes of each packet being ACKed. In the current design, these are pseudorandom as long as the content (or basically anything at all about the packetization) is at all unpredictable, because it's either ciphertext or the authentication tag. If we want, we can always add an "entropy" frame that randomizes the packet; it can be relatively short (one byte) because the combinatorics add up very quickly.

[martinthomson]

Even the existence of an "entropy" frame would work. Also, you can randomize MAX_[STREAM_]DATA to get the same effect.

[ekr]

Or randomize the order of the frames in the packet.

[igorlord]

Or randomize the order of the frames in the packet.

Let's not do this or rely on this. Since endpoints will usually process frames in order, the sender may wish to put these frames in a particular order (order of priority, for example).

[martinthomson]

At the interim, we discussed this design and decided that it was too similar to the one-bit version of this design - the entropy bit - that was part of earlier versions of the protocol. People were very happy to have the entropy bit removed because it was quite onerous to implement. Instead, we are now looking at defining an explicit proof of receipt packet. See #161 (comment) for some more details on that.