Re: [quicwg/base-drafts] Preventing KEY_PHASE bit from being used as a tool to correlate CIDs (#1322)

[Martin Thomson <[e-mail]>]

I don't think that PN mod 2<sup>32</sup> works without trial decryption.

Let's say that we have an 8 bit encoding and we are approaching the crossover point.  When the crossover happens, the recipient uses the old PN key and gets a random 8 bit value, which might be a valid value less than the crossover point.  That packet will fail to be decrypted.

I also agree with @marten-seemann that we should favour designs that are based on explicit signals rather than simple counts.  2<sup>32</sup> is large enough that some implementations might not encounter the rollover point.  I have experience with fixed rollovers in NSS and testing them is ugly.  On the other hand, sending KeyUpdate is easy.  I don't think that a randomized packet number is the right fix for that.

Finally, though I suspect @janaiyengar is right with respect to per-CID spaces, but the decision to roll keys based on a change in connection ID can be made without going that far.  All we need to do is decide to keep the sequencing of connection IDs.  We also need to recognize that two sets of keys might be maintained for some time during migration; that would be somewhat longer than the text currently suggests because of probing, but it's not that much.

-- 
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/1322#issuecomment-386486688