RE: Simple transform for improving PN ossification prevention

[Praveen Balasubramanian <[e-mail]>]

I opened issue #1296<https://github.com/quicwg/base-drafts/issues/1296> for tracking PN transform negotiation.

From: QUIC [mailto:[e-mail]] On Behalf Of Praveen Balasubramanian
Sent: Thursday, April 12, 2018 9:29 AM
To: Mikkel Fahnøe Jørgensen <[e-mail]>; Martin Thomson <[e-mail]>
Cc: Ryan Hamilton <[e-mail]>; Fossati, Thomas (Nokia - GB/Cambridge) <[e-mail]>; Brian Trammell (IETF) <[e-mail]>; Victor Vasiliev <[e-mail]>; IETF QUIC WG <[e-mail]>; Kazuho Oku <[e-mail]>
Subject: RE: Simple transform for improving PN ossification prevention


Re. #1079, following seems like a way forward so we get to do some implementations and get data:

  1.  PN transform is negotiated using transport params.
  2.  Following PN transforms are supported:
     *   PNE

Connections expecting to use multiple paths due to gratuitous/voluntary migration MUST negotiate and use PNE transform. See issue 1271 where options are being discussed on how migration could be negotiated.

Revisit this solution for proper multi-path after designing multiple PN spaces. I am fine if this is done for V2.

     *   Low cost ossification prevention transform (like shuffle).

For connections on the Internet on single path require them to negotiate this transform. Even better if we find another low cost scheme with better properties before we ship V1.

     *   No-op (current draft)

For intra-datacenter or single domain private network scenarios allow usage of the no-op transform.

If server fails to negotiate PNE and supplies multiple connection IDs for migration, client fail the connection.
If the server fails to negotiate a low cost transform on the Internet, client fails the connection.

Please note that servers are free to pick PNE all the time. This allows server deployments which have no performance concern to always use PNE. I do have some battery life concerns on client side, but I do think the major perf concern is on server side.

If the deployments using low cost transform hit middlebox issues they will suffer and pay the cost to do PNE.

From: Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
Sent: Thursday, April 12, 2018 3:52 AM
To: Martin Thomson <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>; Brian Trammell (IETF) <[e-mail]<mailto:[e-mail]>>; Ryan Hamilton <[e-mail]<mailto:[e-mail]>>; Victor Vasiliev <[e-mail]<mailto:[e-mail]>>; Fossati, Thomas (Nokia - GB/Cambridge) <[e-mail]<mailto:[e-mail]>>; Kazuho Oku <[e-mail]<mailto:[e-mail]>>; Praveen Balasubramanian <[e-mail]<mailto:[e-mail]>>
Subject: Re: Simple transform for improving PN ossification prevention



On 12 April 2018 at 11.05.17, Martin Thomson ([e-mail]<mailto:[e-mail]>) wrote:
The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described. Those problems exist if the signal exists
at all.



True. But these are still the options as I see it. Half-baked obfuscation will only make it worse.

There is the holy grail of fast 32-bit permutations that can be used directly as IV, which are sufficiently safe wrt. privacy, and where the permutation does not depend on the packet content.

The following function is useful to disperse a low-quality hash - it is a perfect permutation. Unfortunately, or fortunately, it can be trivially reversed - see stack overflow article. There are also 64-bit variants, and it could also be just a single multiplication. Martin T. already hinted at something similar in an earlier mail.

The benefit of this over lower octet permutation is that stupid middle-boxes don’t have a chance, while slightly intelligent middle-boxes can use it is loss / reordering signal, and QUIC hardware offload decryptors can use the value unmodified as IV rather than computing the inverse first. From a privacy perspective this is no better than plain sequential numbers.

But it still serves as fingerprinting a given QUIC version. I’d say full encryption or clear text sequential are the only viable choices.





    /* http://stackoverflow.com/a/12996028<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstackoverflow.com%2Fa%2F12996028&data=02%7C01%7Cpravb%40microsoft.com%7Ca2c88dcbb1514646489e08d5a0637623%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636591271404538121&sdata=VA8DpVcyhVKyWOMKScnhomUQySGb9q3x1rdYKsctwf0%3D&reserved=0> */

    uint32_t x = type_hash;



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

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

    x = ((x >> 16) ^ x);

    return x;