Subject: [quicwg/base-drafts] Packet protection keys not CID-based (#1267)

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Apr 2018 11:09:04 -0700

@igorlord proposed a possible strategy to mitigate timing attacks / gaps in observable packet numbers from different CIDs, particularly in the case of random offsets per CID.  He would send identical packet payload, modulo some PADDING to avoid them being identically-sized, under the same packet number with different CIDs and a random delay on one of them.  An observer would no longer see matching gaps between packets from two different CIDs and be able to probabilistically correlate them as easily.  The receiver, seeing a duplicate packet number, will discard whichever arrives later.

This doesn't appear to work in the current packet protection scheme because, post-handshake, the packet protection keys don't mix in the connection ID, as far as I can tell.  That means identical packet numbers produce identical IVs and compromise the payload of the packets (assuming the observer can correlate them some other way).

However, if the packet protection secrets were derived from the Connection ID as well as the TLS exporter value, then identical packet numbers on different CIDs would not be a security issue.  This might also be a necessary property if we pursue per-CID packet number spaces.

-- 
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/1267

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Apr 2018 17:10:24 -0700

That's an interesting suggestion, certainly.  The predecessor to #1079 actually did that, but it turned out to be a little painful.

@ekr privately suggested that it might be necessary to send packets on the old path after a migration for other reasons.  That would help avoid denial of service caused by rewriting source addresses, or similar sorts of attacks.

FWIW, I don't think that the cessation of transmission on one path and commencement on another is as directly correlateable as that discussion implied, but I'm certainly not opposed to strategies that make any correlation harder.

-- 
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/1267#issuecomment-379112626