Re: Packet number encryption

[Eric Rescorla <[e-mail]>]

On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar <[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

-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]> 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]] On Behalf Of Stephen Farrell
>> Sent: Tuesday, February 6, 2018 7:35 AM
>> To: Mirja Kühlewind <[e-mail]>; Mikkel Fahnøe
>> Jørgensen <[e-mail]>; Brian Trammell (IETF) <[e-mail]>;
>> Jana Iyengar <[e-mail]>
>> Cc: Praveen Balasubramanian <[e-mail]>; QUIC WG <[e-mail]>;
>> Roberto Peon <[e-mail]>; Lubashev, Igor <[e-mail]>; Salz,
>> Rich <[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;-)
>>
>
>