Subject: Re: [quicwg/base-drafts] Timing side-channel on key updates (#2792)

From: ekr <[email-masked]>
Date: Tue, 23 Jul 2019 07:27:26 -0700

To recap my comments at the mic: it's not clear to me what the attacker is learning here. Can someone expand on this?

-- 
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/2792#issuecomment-514233988

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jul 2019 07:30:41 -0700

Discussed in Montreal: @marten-seemann to work with @martinthomson and @ekr to work out the details

-- 
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/2792#issuecomment-514235427

---

From: Christopher Wood <[email-masked]>
Date: Tue, 30 Jul 2019 19:54:37 -0700

I'd like to second @ekr's comment at the mic. I don’t think this is an issue for which we need text. Without loss of generality, let’s assume that in the worst case an attacker learns the entire unprotected header bytes for every packet. (That is, that header protection does nothing overwhelmingly helpful.) Revisiting the header protection algorithm, it basically works as follows:

~~~
H’ = H XOR mask
     = H XOR PRP(hp_key, sample)
~~~

where H’ and H are the protected and unprotected header bytes, respectively, and sample is known to the adversary. If we assume mask is the output of a PRP, and therefore both IND-CPA secure and KPA secure, an adversary learns nothing from known plaintext and ciphertext pairs. (The typical game-based IND-CPA security definition says that an adversary with access to an oracle for encrypting any message M_i of its choice has negligible probability in selecting b, upon giving the challenger M_0 and M_1 and receiving an encryption of M_b. Recovering the header protection key would break this assumption, as it would let the adversary encrypt M_0 and M_1 -- without the oracle -- and trivially match against M_b.)

All that said, adding text describing that endpoints should precompute keys is probably fine. I’m just not sure it’s needed here.

-- 
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/2792#issuecomment-516673024