Subject: [quicwg/base-drafts] Proof of receipt of packets in ACK (#509)

From: ekr <[email-masked]>
Date: Sun, 07 May 2017 17:15:42 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/509

---

From: Martin Thomson <[email-masked]>
Date: Sun, 07 May 2017 17:17:05 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/509#issuecomment-299746254

---

From: ekr <[email-masked]>
Date: Sun, 07 May 2017 17:56:10 -0700

Or randomize the frames in the packet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/509#issuecomment-299748819

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 18 May 2017 15:45:53 -0700

> 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).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/509#issuecomment-302561981