Subject: [quicwg/base-drafts] Packet number transform should be negotiated (#1296)

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Apr 2018 12:08:27 -0700

Packet number encryption has been proposed as a method to prevent ossification as well as improve privacy of connection migration. However there is a performance cost of doing the transform. There are deployments where ossification is not a concern (intra-DC, private network) and there are connections which are single path where privacy is not a concern, only ossification is. 

Hence packet number transform needs to be a negotiation with the caveat that the negotiated transform must meet the requirements for the deployment scenario otherwise the connection should be failed.
 
Packet number transform can be negotiated using transport parameters. Following PN transforms should be supported:

1. Packet number encryption (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. If a client or server fails to negotiate PNE and negotiates connection migration, fail the connection.
2. Low CPU cost ossification prevention transform (like shuffle)
For connections on the Internet on single path require them to negotiate this transform. If client or server fails to negotiate this transform on the Internet, fail the connection. 
3. No-op (current draft) 
For intra-datacenter or single domain private network scenarios allow usage of the no-op transform. This is for constrained deployments so clients should not negotiate this transform by default.

Servers are free to negotiate PNE all the time. This allows server deployments which have no performance concerns to always use PNE. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1296

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Apr 2018 12:16:06 -0700

It needs to be determined what is set as the client initial (CI) packet number, since that is sent before any negotiation. The solution is the same as what we do for client connection ID, pick a random packet number and only apply the transform to subsequent packets per negotiation. There is also some discussion that the PN space for negotiation should be different (in context of the stream 0 improvements) so this may fit in more neatly in future. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1296#issuecomment-382109506

---

From: janaiyengar <[email-masked]>
Date: Tue, 24 Apr 2018 01:42:00 +0000 (UTC)

It occurs to me that you can always encrypt PN on long headers, and negotiate the transform for short headers. This ensures that a transform is negotiated for the performance-driving case, at the same time avoiding ossification issues for early packets. But yes, there might be a new PN space for the handhshake, which will make this easier to handle.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1296#issuecomment-383775712

---

From: MikkelFJ <[email-masked]>
Date: Tue, 24 Apr 2018 00:34:30 -0700

I'm a bit worried that this negotiation could lead to more overhead than finding one good solution, but it depends on whether a good solution is indeed found.

For example: assuming PN space per path handles privacy without encryption leaving only the issues:
1) ossification
2) early packet reject on assumed invalid PN

A cheap seeded multiplication can handle these issues if offline attack and privacy are not a concern. Some other cheap solution could probably also be found, but there is hardly any reason to negotiate then - except if clear text PN is a specific objective.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1296#issuecomment-383833186