RE: Packet number encryption

[Mike Bishop <[e-mail]>]

#2 won’t work.  The packet number is an input to the AEAD nonce, so you have to get to the packet number before you can decrypt the payload.  It can’t be based on anything internal to the encrypted packet.

In Martin’s proposal, it’s using a combination of the encrypted payload (which requires nothing to access) and some stored state on each endpoint, which requires only the Connection ID to look up.  You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet numbers and start drawing inferences about what the XOR value is.  If overhead is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize the cost of doing the encryption step.  (At the cost of keeping the table of precomputed values, of course.)

I still think Jana’s pushing in the right direction here:  Let’s agree on goals, and then see if we can craft a design that meets those goals.  I hear you saying that low overhead is a goal, which I think we can all agree on.  I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like there’s less agreement on that.  You also raise an interesting point that some clients will care less about linkability because they will never intentionally migrate.

From: QUIC [mailto:[e-mail]] On Behalf Of Praveen Balasubramanian
Sent: Wednesday, February 7, 2018 9:44 AM
To: Marten Seemann <[e-mail]>; huitema <[e-mail]>
Cc: [e-mail]
Subject: RE: Packet number encryption


Couple of things to add:

1. Connection migration is an optional portion of the transport and not mandatory. It does not seem to be incrementally deployable with today's unmodified load balancers. Many devices may also be single homed and not have multiple active network interfaces. I also think the app and system settings will have to opt-in to it (to prevent aggressive usage of metered cellular data). If this is the case, cross-path linkability will be of limited concern for many QUIC connections. There is also the fact that perfect unlinkability seems to be hard against a motivated adversary.

2. If middlebox ossification is a big concern, we mainly need obfuscation and not encryption. Another option for example would be an XOR transform with some variable field in the encrypted portion of the packet (as an example sequence number of the first stream frame if it is present or some random pad bytes when its not present). I hope we can be creative here to reduce computation cost.


From: Marten Seemann [mailto:[e-mail]]
Sent: Wednesday, February 7, 2018 12:01 AM
To: huitema <[e-mail]<mailto:[e-mail]>>
Cc: Praveen Balasubramanian <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Packet number encryption


On Wed, Feb 7, 2018 at 3:20 PM Christian Huitema <[e-mail]<mailto:[e-mail]>> wrote:



On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote:

First, the proposal does not obscure the position of the packet number field in the header. The field contains a number that increments with every packet, and is thus easy to identify. This means that middle-boxes will get accustomed to seeing that field and tracking its increments.

Hence, this simple obfuscation provides no protection against ossification of the packet number field.



Well it seems like it is a requirement (see bullet 3 in Jana's list) to allow middleboxes to see sequencing information. By picking the initial random value middleboxes cannot assume any particular value. If packet number location and size is not part of invariants then it cannot be ossified, middleboxes will need to be resilient.

This is why I would rather see the exposed bits copied at a fixed location, while the PN itself cannot be located. That way, the exposed bits can ossify, but the actual PN does not.

We still need to be very careful here. If we decide to expose bits, we must make sure that a middlebox can only extract coarse-grained information, if we want to prevent middleboxes from buffering and delaying packets in order to fix / reduce reordering.
At this point however, I'm not convinced that exposing any reordering information to the network should be a requirement at all. There's a real risk of misuse of this information, and of ossification of whatever bits we expose.