Change Packet Number Gap to Packet Number Offset #1307

nibanks · 2018-04-19T21:29:05Z

This is a proposed solution to the privacy/linkability problem by slightly modifying the existing packet number gap solution to make it a per connection ID packet number offset. The offset is used to transform the wire encoding of the packet number, but the connection still uses the same monotonically increasing packet number space (no gaps).

This solution requires very little per packet CPU overhead, compared to PNE.

Unlike the PNE proposal (#1079), this doesn't fix the ossification/greasing problem as well. Instead, I'd like to treat that as a separate problem (and a separate PR) and attempt to solve that with a non-cryptographic solution (shuffle for instance).

Closes:

marten-seemann · 2018-04-19T23:45:02Z

draft-ietf-quic-transport.md

+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:


Why does this only apply to new connection IDs? Wouldn't it be easier to apply this transformation to every packet number?

I was just following the existing model that gaps used. I don't have a strong opinion either way.

The gap in the actual packet number was introduced at the point you sent the first packet with a new CID. This proposal is a transformation of the actual packet number for wire presentation, so it needs to occur every time.

I think that's a clear mistake, the transformation should apply to all packet numbers on the network

huitema · 2018-04-20T02:00:48Z

I think that's a terrible idea. It perpetuates the fallacy that offsetting packet numbers provides privacy. We have established that it doesn't in an important case, when there is overlap between two connections. The matching pattern of holes and sequence number increment is more that sufficient to establish correlation in these cases.

We would be much better off just getting rid of the gaps altogether. They force complex synchronization between sender and receiver, effectively the same management cost as managing encryption keys, but they do not provide nearly as much benefit as encryption.

nibanks · 2018-04-20T13:19:32Z

@huitema would adding the shuffle (or some other non-cryptographic greasing) alleviate your concerns here? Matching patterns between overlap would be more difficult then.

As for this design being a complex synchronization between sender and receiver, I disagree with you. Each side needs only generate the offset once, per connection ID and just store that offset. When sending, it's just an additional add and modulo operation. The receiver just needs to do an add and subtraction operation.

Obviously adding whatever greasing algorithm will add additional complexity, but the CPU cost per packet should still be quite low, and easily implemented in hardware.

mikkelfj · 2018-04-20T13:51:02Z

@nibanks this looks a bit like my segmented packet numbers proposal but not that this proposal has a fixed offset per connection ID and that a connection ID is replaced before that offset is exhausted.

This avoids any linkage other than NAT rebinding.

#1105

You can further mutilate the clean packet number sequence with a reversible permutation

http://stackoverflow.com/a/12996028

   uint32_t x;

    x = ((uint32_t)(size_t)PN) ^ (uint32_t)(MY_SEED);

    x = ((x >> 16) ^ x) * 0x45d9f3bUL;
    x = ((x >> 16) ^ x) * 0x45d9f3bUL;
    x = ((x >> 16) ^ x);
    return x;

And you can further encrypt that permutation using simple XOR magic - apparently IPSec style.

mikkelfj · 2018-04-20T13:55:44Z

Just using a random seed might be sufficient to deter the average middle box and with CID update there is no privacy leak.
The resulting PN can be used as AEAD IV since it is a permutation of a unique non-repeating sequence. After CID update the AEAD keys must change, but then it is about time anyway.

mikkelfj · 2018-04-20T14:08:26Z

I suppose a more elaborate encryption would go like

uint32_t key[4];
hkdf(key, context);

uint32_t x;

    x = ((uint32_t)(size_t)PN) ^ key[0];
    x = ((x >> 16) ^ x) * UINT32_C(0x45d9f3b) ^ key[1];
    x = ((x >> 16) ^ x) * UINT32_C(0x45d9f3b) ^ key[2] ;
    x = ((x >> 16) ^ x) * UINT32_C(0x45d9f3b) ^ key[3];
    x = ((x >> 16) ^ x);
    return x;

Due to brute force the encryption is not strong, but combined with per path CID and update before 2^32 PN's it should be robust since the PN encryption is not privacy.

To speed things up, one or two multiplication rounds can be taken out.

See also
http://stackoverflow.com/a/12996028

mikkelfj · 2018-04-20T14:13:12Z

The above cannot be used directly as IV because the permuation is no longer a 1 to 1 mapping but a key guided mapping, so the encrypted PN will not work as an IV. The same issue should not be the case with the initial seeded value.

MikeBishop · 2018-04-20T17:22:20Z

After CID update the AEAD keys must change, but then it is about time anyway.

Given how frequently CID rotation might occur (path validation, quiescence, shifts in wind direction), I am dubious that it's wise to rotate 1-RTT keys every time a new CID is used, which I believe is what you're saying here. This also falls prey to the same problem as #1174 -- if you switched keys because you used a new CID to probe, what key do you use back on the original path while you wait for the probe to complete? Key rotation is supposed to be a ratchet forward, and you can't have two key rotations going on at once in the current design, so you also can't take the answer of doing a second rotation on the original path.

MikeBishop

I think @marten-seemann is correct -- this solution only makes sense as a transform on every packet, not just as something to do on particular packets with a new CID. That's my key feedback on fixing the PR.

On the proposal itself, however, I share @huitema's concerns that correlation of gaps between flows is still possible. A future PR for a shuffle can make that harder for an observer, but only so much (observing over the shuffle window, you can perform the same analysis).

MikeBishop · 2018-04-20T17:38:27Z

draft-ietf-quic-transport.md

+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:


The gap in the actual packet number was introduced at the point you sent the first packet with a new CID. This proposal is a transformation of the actual packet number for wire presentation, so it needs to occur every time.

MikeBishop · 2018-04-20T17:40:32Z

draft-ietf-quic-transport.md

+transform the packet number via the following:
+
+~~~
+transformed_packet_number = (packet_number + offset) % 2^62


This might actually be okay, but the possibility that the transformed packet number might wrap around to zero before being truncated feels a little odd.

MikeBishop · 2018-04-20T17:42:32Z

draft-ietf-quic-transport.md

+~~~
+
+Once transformed, the normal rules of packet number encoding are followed, only
+encoding the least number of bits required.


"only" and "the least" feels duplicative. Maybe just replace the part with the comma with a reference to the section where the truncation is defined?

Better yet, since this is effectively a transform on every packet number, put this in the section about truncation (it becomes a description of how the 64-bit number is encoded on the wire) and make this section purely about determining what the offset will be.

mikkelfj · 2018-04-20T18:43:50Z

if you switched keys because you used a new CID to probe, what key do you use back on the original path while you wait for the probe to complete?

I forgot about my own proposal: No, rekeying is not needed for each new CID. The segmented packet number idea means that each CID is given an internal incremental high bit value. So the IV is the CID counter + the visible PN, permutated or not. Hence the AEAD can last much longer than CID's

Count(CID) * 2^32 + permuation(PN){unique in 32 bits, per CID}

However, for the sake of privacy, you need to do a a high bit increment for each CID, but that is also very cheap.

huitema · 2018-04-20T19:31:48Z

This design falls in the category of "obfuscation", analyzed in https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives#alternative-pn-encryption. It does not provide privacy, and also does not protect against ossification. You would be better off leaving the PN in clear text.

mikkelfj · 2018-04-20T20:34:51Z

You would be better off leaving the PN in clear text.

That was also my original intend, but it does offer privacy because it is unique per CID and there is no visible gap to be compared across CID's (modulo NAT rebinding). As to obfuscation, if seeded with an unguessable value, and filtered for the zero case, it would not be unbreakable, but neither would it be very trivial to make use of in a busy switch. So it comes down to how much you wan't to harden against ossification - if the answer is "very" then full PNE is the only way.

ad-l · 2018-04-23T12:35:11Z

@MikeBishop is right - the proposal only makes sense if it applies to all packets, so the text about this being only for new connection IDs must be removed

nibanks · 2018-05-03T19:47:32Z

No longer necessary as PNE was merged.

Packet Number Gap -> Offset

2b291fa

nibanks mentioned this pull request Apr 19, 2018

Packet number encryption #1079

Merged

marten-seemann reviewed Apr 19, 2018

View reviewed changes

MikeBishop requested changes Apr 20, 2018

View reviewed changes

nibanks closed this May 3, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Change Packet Number Gap to Packet Number Offset #1307

Change Packet Number Gap to Packet Number Offset #1307

nibanks commented Apr 19, 2018

marten-seemann Apr 19, 2018

nibanks Apr 20, 2018

MikeBishop Apr 20, 2018

ad-l Apr 23, 2018 •

edited

Loading

huitema commented Apr 20, 2018

nibanks commented Apr 20, 2018 •

edited

Loading

mikkelfj commented Apr 20, 2018 •

edited

Loading

mikkelfj commented Apr 20, 2018

mikkelfj commented Apr 20, 2018

mikkelfj commented Apr 20, 2018

MikeBishop commented Apr 20, 2018

MikeBishop left a comment

MikeBishop Apr 20, 2018

MikeBishop Apr 20, 2018

MikeBishop Apr 20, 2018

mikkelfj commented Apr 20, 2018 •

edited

Loading

huitema commented Apr 20, 2018

mikkelfj commented Apr 20, 2018 •

edited

Loading

ad-l commented Apr 23, 2018

nibanks commented May 3, 2018

Change Packet Number Gap to Packet Number Offset #1307

Change Packet Number Gap to Packet Number Offset #1307

Conversation

nibanks commented Apr 19, 2018

marten-seemann Apr 19, 2018

Choose a reason for hiding this comment

nibanks Apr 20, 2018

Choose a reason for hiding this comment

MikeBishop Apr 20, 2018

Choose a reason for hiding this comment

ad-l Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

huitema commented Apr 20, 2018

nibanks commented Apr 20, 2018 • edited Loading

mikkelfj commented Apr 20, 2018 • edited Loading

mikkelfj commented Apr 20, 2018

mikkelfj commented Apr 20, 2018

mikkelfj commented Apr 20, 2018

MikeBishop commented Apr 20, 2018

MikeBishop left a comment

Choose a reason for hiding this comment

MikeBishop Apr 20, 2018

Choose a reason for hiding this comment

MikeBishop Apr 20, 2018

Choose a reason for hiding this comment

MikeBishop Apr 20, 2018

Choose a reason for hiding this comment

mikkelfj commented Apr 20, 2018 • edited Loading

huitema commented Apr 20, 2018

mikkelfj commented Apr 20, 2018 • edited Loading

ad-l commented Apr 23, 2018

nibanks commented May 3, 2018

ad-l Apr 23, 2018 •

edited

Loading

nibanks commented Apr 20, 2018 •

edited

Loading

mikkelfj commented Apr 20, 2018 •

edited

Loading

mikkelfj commented Apr 20, 2018 •

edited

Loading

mikkelfj commented Apr 20, 2018 •

edited

Loading