RE: Packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

One aspect of randomised gaps that might be overlooked is that packet
numbers are only sent with the lower 4 bytes at most. This means that a
randomised gap on a new connection ID is not different from a new packet
number that starts at a random offset because you cannot tell if it rolled
over without knowing more about the connection.

However, if migration does not look like a new connection, at least a
0-RTT, it is all a mood point because the sudden appearance of data on a
new connection ID combined with the silence of another ID, and probably
also characteristic changes in packet delays and sizes during migration,
along with GeoIP, are all fingerprinting the connection.

On monitoring packets inside a network, there are probably many new
unexplored possibilities to track reordering of encrypted packet numbers.
For example, one could create a bloom filter to record the packet numbers
seen in a block of N packets, for example syncing wherever the lower packet
number bits are all 0, or something. Packet loss would show up as fewer
matches when comparing filters at different nodes. Or the lower 8 bits of
each packet number in a block could be concatenated to a string and
compared with levenshtein edit distance - even just the lower two bits of
each packet might suffice. The fact the packet numbers are random could be
used pro-actively to simplify hashing.

While the above has some statistical uncertainties, and they do require a
bit more data and time, they also possibly look at longer sequences and
thereby give an overall better quality of understanding than just looking
for out of sequence numbers. After developing good hashes that somehow
encode ordering relations, a neural network might be trained to identify
abnormal traffic patterns efficiently.

Mikkel

On 4 February 2018 at 20.55.59, Praveen Balasubramanian ([e-mail])
wrote:

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