RE: Packet number encryption

[Praveen Balasubramanian <[e-mail]>]

Great framing of the problem.

Proposal: Transform = Add a secure and fixed random offset to the actual packet number for the lifetime of one path. Transport level packet numbers start at 0. On wire packet number start at the offset. Client and server pick the offsets independently. Each side communicates this offset number in an encrypted frame until the first ACK. Other side subtracts the offset to figure out actual packet number and uses that to maintain receiver state and generate ACKs.


  1.  Packet number must be unlinkable across connection ID change (for migration.)
Each path gets a new secure random increment so maintains unlikability


  1.  Packet number must start at an arbitrary value, to avoid ossification of the first packet number.
True by definition for on wire packet number


  1.  Some sequencing information -- a few bits of the packet number perhaps -- should be revealed (for monitoring. Number of bits TBD.)
All of the bits are revealed on the wire and in sequence


  1.  Any packet number transformation should not be compute intensive.
Not at all compute intensive

From: Ian Swett [mailto:[e-mail]]
Sent: Tuesday, February 6, 2018 5:05 PM
To: Eric Rescorla <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Praveen Balasubramanian <[e-mail]>; Lubashev, Igor <[e-mail]>; Roberto Peon <[e-mail]>; Mike Bishop <[e-mail]>; Salz, Rich <[e-mail]>; Mirja Kühlewind <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; Brian Trammell (IETF) <[e-mail]>; Stephen Farrell <[e-mail]>
Subject: Re: Packet number encryption

Thanks Jana, I think this is a nice framing of the problem and discussion.

On Tue, Feb 6, 2018 at 7:13 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:


On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
I'm going to try a different attempt at moving towards convergence. Thinking about this some more, and picking up something that Mirja said way earlier in this thread, I think the following decomposition is useful.

1. In the transport, all packet numbers start at 0, increasing monotonically. ACK frames carry these packet numbers, and therefore do not have to span large gaps and do not have to deal with increases in the size of the largest acked. Basically, no gaps are visible within the transport processing engine.
2. Before sending a packet on the wire, and before processing the packet, QUIC transforms the packet number with some function, replacing the visible packet number with the transformed value.

I think we can all agree that (1) is goodness. A sender is also free to use packet numbers from non-contiguous spaces here FWIW, but that's entirely independent of what's visible on the wire. This helps me separate transport processing complexity from the rest of it, which I think is helpful.

I think we are disagreeing on the precise properties we want from the transformation in (2). If we can agree on these properties, we can then figure out whether it's possible and how to construct such a transform. Here's a union of what folks are concerned about:
1. Packet number must be unlinkable across connection ID change (for migration.)
2. Packet number must start at an arbitrary value, to avoid ossification of the first packet number.
3. Some sequencing information -- a few bits of the packet number perhaps -- should be revealed (for monitoring. Number of bits TBD.)

I'm not sure I am persuaded of this point

Yes, I think this seems like the largest point of contention, and #4 is the second largest concern.  Given that, I think it makes sense to try to resolve #3, if that is possible.


-Ekr

4. Any packet number transformation should not be compute intensive.

I'm not looking for a construction, but I'd like to agree on the problem first. Does this sound like the set of properties we want? Or is there a contradiction among these properties that I'm not seeing?

On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:
Packet number encryption *does* improve linkability equivalently to random jumps, but without the fragmentation of the ACK packet which those jumps otherwise cause.  So I'm with Stephen, we don't yet have agreement on that assertion.

-----Original Message-----
From: QUIC [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Stephen Farrell
Sent: Tuesday, February 6, 2018 7:35 AM
To: Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>; Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>>; Brian Trammell (IETF) <[e-mail]<mailto:[e-mail]>>; Jana Iyengar <[e-mail]<mailto:[e-mail]>>
Cc: Praveen Balasubramanian <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>; Roberto Peon <[e-mail]<mailto:[e-mail]>>; Lubashev, Igor <[e-mail]<mailto:[e-mail]>>; Salz, Rich <[e-mail]<mailto:[e-mail]>>
Subject: Re: Packet number encryption


On 06/02/18 15:23, Mirja Kühlewind wrote:
>
> It's also my understanding that we do agree that packet number
> encryption does not help likability (and thereby privacy) a lot, or at
> least that the benefits we might get (or not) do not justify the
> additional complexity.

FWIW, which isn't much, I don't (yet) agree to the above.
I reckon it'll be a while before we know how linkability pans out. I do agree that packet number encryption is not a panacea for unlinkability, but it may help, or may even end up being required, to do a good job wrt linkability.

I also heard people say it was less complex for them so "additional complexity" may also not be quite right. (I guess "differently complex" is correct though.)

S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)