RE: Packet number encryption

[Praveen Balasubramanian <[e-mail]>]

Ok this answers my question that this is targeted at the migration scenario. 

If jumps are random and cryptographically seeded I don't understand why there would be a pattern. We already use this type of mechanism for TCP ISN and IP header Identification fields. The adversary could also use the side channel timing attack of just observing the sending and receiving application rate for correlation between the two paths (after factoring in the RTT). 

If independent sequence space (with randomization) can work just as well I'd rather pick that over encryption for efficiency reasons. It should solve ossification but I am not a privacy expert.

-----Original Message-----
From: Christian Huitema [mailto:[e-mail]] 
Sent: Sunday, February 4, 2018 11:46 AM
To: Praveen Balasubramanian <[e-mail]>
Cc: [e-mail]; Gorry Fairhust <[e-mail]>; Eric Rescorla <[e-mail]>; Brian Trammell <[e-mail]>; Lubashev, Igor <[e-mail]>; Roberto Peon <[e-mail]>; Fossati, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]>; Roni Even (A) <[e-mail]>; Mirja Kühlewind <[e-mail]>; Jana Iyengar <[e-mail]>; Eggert, Lars <[e-mail]>; Martin Thomson <[e-mail]>; Piotr Galecki <[e-mail]>
Subject: Re: Packet number encryption



> On Feb 4, 2018, at 9:31 AM, Praveen Balasubramanian <[e-mail]> wrote:
> 
> From the charter "This work will ensure that QUIC has security and privacy properties that are at least as good as a stack composed of TLS 1.3  using TCP (or MPTCP when using multipath)."
> 
> Is the discussion mainly focused on connection migration which is not present in TCP? There seem to be bigger privacy problems due to DNS and TLS SNI extension so in real deployments will packet number encryption add value other than preventing ossification? 

Yes, we need to fix the SNI issue. Clear text ALPN too. But should not prevent us from fixing everything else.

> 
> Is a cryptographically secure random initial packet number and random (forward) jumps in packet number not good enough to prevent ossification? The missing packet number range due to the forward jump could be communicated in the encrypted payload so the receiver knows they are not missing.
> 

No, random jumps are not enough. It turns out that during migration packets are often sent simultaneously on both paths. The pattern of increases and holes is enough to correlate the two paths.

In practice there are two possible designs: packet number encryption as currently documented; or, independent sequence number space and encryption context for each path. Both work. The one we have is significantly easier to implement. The other exposes the sequence number, which may ease network monitoring but also could drive ossification.

Now is a good time to have this discussion.

-- Christian Huitema