Subject: Re: [quicwg/base-drafts] per-CID PN space to avoid PN leak becoming a privacy issue? (#1317)

From: MikkelFJ <[email-masked]>
Date: Tue, 01 May 2018 00:07:50 -0700

Per CID PN avoids inefficient ACK frames because a linear space per CID will lead to a few contigous blocks rather than scattered holes in the PN range due to different latency.

Per CID PN also helps making accurate congestion control per path.

As to keyphase discussed here and elsewehre - I agree that it makes sense to replace keyphase with a CID change, but make it optional to change key when CID changes and change CID no later than 2^32 - which also supports per CID PN with high bit counter per path if so desired. Since different paths likely reach their limit at different times, linkage is reduced, but a CID change can also happen probalisitically after say 2^31 packets.

-- 
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/1317#issuecomment-385613351

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 03 May 2018 13:15:47 +0000 (UTC)

@martinthomson 
> Yes, during the period that you are probing one path and using another, there would be two sets of keys in play. If we went full multipath, then we'd need one key per path. Keep in mind that a set of keys is pretty small - 44 octets plus overheads - much smaller than the amount of state you need to keep for a migration.
> 
> I'm not a big fan of trial decryption, even as constrained as your suggestion would have.

I personally agree that using separate encryption keys makes sense if we decide to have separate PN space per CID.

OTOH, as suggested in https://github.com/quicwg/base-drafts/issues/1322#issuecomment-386290369, I now think we might have a very simple solution _if_ we decide to continue using unified PN space.

-- 
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/1317#issuecomment-386291536