Re: Packet number encryption

[Christian Huitema <[e-mail]>]

On 2/6/2018 1:00 PM, Jana Iyengar wrote:
> 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.)

Yes. And note the special case when the old and new connection overlap
for some time, so that packet N and N+2 may be sent on the old
connection, packet N+1 and N+3 on the new one. That kind of pattern
should be hidden.

> 2. Packet number must start at an arbitrary value, to avoid
> ossification of the first packet number.

Please explain the reasoning. What do you call packet number there, the
value in the ACK or the value in the header?

> 3. Some sequencing information -- a few bits of the packet number
> perhaps -- should be revealed (for monitoring. Number of bits TBD.)

Careful there. This is per path information, so the network might
monitor the quality of a path. To continue my example of N and N+2 on
the old connection, packet N+1 and N+3 on the new one, I would expose x
and x+1 on the old path, y and y+1 on the new path.

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

For some definition of compute intensive. The current PN encryption spec
costs 1 block operation; that compares to 8+8 blocks for a 128 byte
payload (encrypt and checksum), 80+80 on a 1280 byte payload -- 6%
encryption overhead on small packets, 0.6% on large ones. That's less
than the difference between AES and Chacha20.

>
> 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?

I am a bit concerned about placing too much emphasis on computation
cost. This can lead to "inventing our own crypto substitute". If the PN
encoding is easy to break, then it will be routinely broken and ossified.

-- Christian Huitema