Re: Getting to consensus on packet number encryption

[Roberto Peon <[e-mail]>]

PN encryption plus multiple (rotating) GUIDs specified on a per-path basis, as discussed in Melbourne do seem able to provide substantively better privacy. With such a scheme nothing appears to be shared from one 5-tuple+GUID to another 5-tuple+GUID.

An implementation that cared deeply about privacy would send packets along both paths for some time. This doesn't seem like something we can reasonable require with the protocol, but it can be allowed by the protocol.


I am not particularly interested in seeing QUIC v1 become the most CPU efficient thing. I'd rather we release it, and continue iterating. Concentrating on features that prevent ossification furthers this goal and allows for an eventual (and possibly better) HW acceleration path later.
-=R

________________________________
From: QUIC <[e-mail]> on behalf of Lubashev, Igor <ilubashe=[e-mail]>
Sent: Wednesday, April 4, 2018 12:55:47 PM
To: Praveen Balasubramanian; Mirja Kühlewind; Mark Nottingham
Cc: Lars Eggert; IETF QUIC WG
Subject: RE: Getting to consensus on packet number encryption

To restate the options:

(1) - Packet number encryption.

(2) - Per-CID offset.

(3) - Plain text PNs across connection migrations.

(4) - Per-CID PN spaces.



None of the alternatives mask the “connection migration” event from an on-path observer.  The “original” connection establishment is done via clearly identifiable handshake packets on a 5-tuple before short-header packets show up, while “connection migration” events are identifiable by the use of a new CID with short-header packets on a new 5-tuple w/o preceding handshake packets.



As it was pointed out many times (especially by Brian), it is not that hard to correlate cessation of packets from one 5-tuple and appearance of a new post-“connection migration” 5-tuple, especially if destination IPs for both are identical.  Moreover, since devices that wish to maintain connections during migration will likely migrate multiple connections, the on-path observer will see a group of 5-tuples from the same IP cease activity, while a similar group of post-“connection migration” 5-tuples appears from a different IP, all with matched destination IPs.



Given the above, I am left wondering if increasing the costs for content hosting, increasing per-packet power requirements for mobile and micro devices, and making the Internet harder to troubleshoot and operate is worth the mostly illusory privacy gains of (1).  Patrick’s “the privacy is a must have” is a desire I share, but does (1) provide privacy against a sophisticated on-path observer?



Yet, (2) seems simple enough and a good compromise.  As Mike points out, it allows an on-path observer who can link CIDs across “connection migrations” to infer PNs.  But if CIDs are already linked, there is no more privacy argument to be made anyway.  One thing (2) does not allow an on-path observer to do is to link CIDs via PN analysis.  (Though it still seems like the privacy gains from any of the above are mostly an illusion.)  So my vote is for (2).



- Igor





-----Original Message-----

From: Praveen Balasubramanian [mailto:pravb=[e-mail]]

Sent: Wednesday, April 04, 2018 3:15 PM

To: Mirja Kühlewind <[e-mail]>; Mark Nottingham <[e-mail]>

Cc: Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>

Subject: RE: Getting to consensus on packet number encryption



I too disagree with the assessment of the situation. +1 to everything Mirja said.



>> there is no *requirement* that we produce a protocol that is able to be accelerated by hardware.

It is however a requirement for deployment that we be able to offload QUIC. A large part of work we do in TCP is acceleration in software and hardware.. If QUIC has to evolve from experiment to broad deployment performance is a key goal. This is brought up several times in TCP working group where we see proposals that wouldn’t work with widely deployed software and hardware accelerations.



Whether we like it or not performance is a key requirement for QUIC on servers and for datacenter scenarios. Even Ian mentioned before that he'd not want to do PNE within DC and I agree. Most connections will also not be doing migration or using multi path so why pay the extra overhead in the common case for no benefit?



Since PNE doesn’t affect the invariants (its simply an extra step post packetization and pre parsing), please explain why it would block progress on other fronts? What is the list of things that get blocked?



Please let us not rush into a design that impacts per packet processing costs with no clear articulation of the problem and the benefits.



>From what I can tell there is wide disagreement in the group and nothing resembling consensus. The fact that we have poor representation from hardware developers and public cloud providers is further skewing the perception.



My recommendations:

1. Leave the current draft as is. Make sure we have some provision for greasing the PN to prevent ossification.

2. Explore multiple PN spaces for connection migration (and eventually multipath).

3. Make PNE an optional negotiated extension for implementations that want to do connection migration in V1 with the caveat that we will revisit this for V2 when we do multipath.

4. Solicit more feedback on the protocol from hardware vendors and public and private cloud providers. I can try to loop in more folks but others should too.



-----Original Message-----

From: QUIC [mailto:[e-mail]] On Behalf Of Mirja Kühlewind

Sent: Wednesday, April 4, 2018 3:27 AM

To: Mark Nottingham <[e-mail]>

Cc: Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>

Subject: Re: Getting to consensus on packet number encryption



Hi Mark,



without intending to state a technical opinion, I think I need to disagree with your assessment of the situation. Please see below.



> Am 04.04.2018 um 06:58 schrieb Mark Nottingham <[e-mail]>:

>

> Hi everyone,

>

> The editors have told your chairs that this issue is starting to block progress on other aspects of QUIC. Coming to consensus on it soon (i.e., before Stockholm, if possible) would be good.

>

> It looks like this thread has come to a natural pause. Reading through it, I think we agree there are some unpleasant tradeoffs here, but so far we have only one concrete proposal -- PR#1079.



The other proposal is to use a random offset that can/should be changed when the connection ID is changed. Which is mostly inline with what the draft currently says.

>

> My AU$.05 - While we're chartered to produce a protocol that's encrypted as much as operational concerns allow,



I don’t think this is what the charter say. The charter says "Providing always-secure transport, using TLS 1.3 by default.“ plus another paragraph that talks about TLS1.3. It does not spell out the desire of some individual to „encrypt as much as possible“.



> and that privacy is a natural extension of that (especially in light of RFC7258 and RFC6973), there is no *requirement* that we produce a protocol that is able to be accelerated by hardware.



Not there is no requirement that the protocol need to be accelerated by hardware. However, not all requirement are listed in the charter. We as a group have to define the requirement. However, there is of course an implicit requirement for all work in the IEFT that is must be deployable and serve the needs of those people who want to deploy it.



>

> That being the case, I think we need to ask ourselves if we believe that inclusion of PR#1079 will significantly inhibit deployment of the protocol. Based on the discussion so far, that doesn't seem to be the case, but I'd be interested to hear what others think.



Here my assessment is also different. There are multiple people that have raised concerns that this could hinder deployment.

>

> If we can get to consensus to incorporate the PR, and folks come back later with a more hardware-friendly replacement that doesn't change the Invariants or increase linkability, I suspect the WG will be amenable to that.



I don’t think to just go with what we have even though there are concerns, is the right approach and definitely not the approach that was chosen for other proposals. In the sake of getting version v1 out quickly, I would think that not incorporating another change that does not have consensus is the proposer approach.



Mirja







>

> What do folks think?

>

> Cheers,

>

>

>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=[e-mail]> wrote:

>>

>> Thanks for the nice summary Jana.

>>

>> As much as I'd love to have easier crypto HW acceleration, I've ended up arriving at the same conclusion.  I don't want to bite off the work to do proper multipath in QUIC v1, which I think is the only other reasonable option of those Christian outlined.

>>

>> If someone comes up with a way to transform packet number to make it non-linkable, but doesn't have the downside of making hardware offload difficult, then I'm open to it.  But we've been talking about this for 2 months without any notable improvements over Martin's PR.

>>

>> Given we never talk about any issue only once in QUIC, I'm sure this will come up again, but for the time being I think #1079 is the best option we have.

>>

>>

>>

>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <[e-mail]> wrote:

>> A few quick thoughts as I catch up on this thread.

>>

>> I spent some time last week working through a design using multiple PN spaces, and it is quite doable. I suspect we'll head towards multiple PN spaces as we consider multipath in the future. That said, there is complexity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convinced that this is necessary as a design primitive for QUICv1.

>>

>> We may want to creatively use the PN bits in v2, say to encode a path ID and a PN, for multipath. We want to retain flexibility in these bits going into v2. We've used encryption to ensure that we don't lose flexibility elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simplicity of design is the other value in using PNE, since handling migration linkability is non-trivial without it.)

>>

>> This leaves the question of HW acceleration being at loggerheads with the design in PR #1079. First, I expect that the primary benefit of acceleration will be in DC environments. Yes, there are some gains to be had in serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceleration. I understand that others may disagree with me here.

>>

>> AFAIK, QUIC has not been used in DC environments yet. I expect there are other things in the protocol that we'd want to change as we gain experience deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experience can drive subsequent changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.

>>

>> So, in short, I think we should go ahead with PR# 1079. This ensures that future versions are guaranteed the flexibility to change the PN bits for better support of HW acceleration or multipath or what-have-you.

>>

>> - jana

>>

>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <[e-mail]> wrote:

>>

>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:

>>> Looking at https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fen.wikipedia.org-252Fwiki-252FAES-5Finstruction-5Fset-2523Intel-5Fand-5FAMD-5Fx86-5Farchitecture-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-26sdata-3DaOHc7FZoIBCE1OlqmNpvdMM0ntLerZ3FpqESVj85zfE-253D-26reserved-3D0&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=ym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=WkBplmuEwMxL-oezaQ4rK1_9-0SXgkY1NJ_V3SPhYOU&e= it seems to imply a large range of server, desktop and mobile chips all have a CPU instruction set available to do AES acceleration and other similar operations (other instruction sets are also available).

>>>

>>> If we are considering the AES instructions then it looks like it is (or at least will be in the near future) a sizeable proportion of the public internet have it to be used.

>>>

>>

>> Certainly, but that's not the current debate. PR #1079 is fully compatible with use of the AES instructions. The issue of the debate is that the mechanism in PR #1079 required double buffering, first encrypt the payload, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that can readily access all bytes of the packet from memory, but it may be an issue in some hardware implementations that are designed to do just one pass over the data.

>>

>>

>> -- Christian Huitema

>>

>>

>>

>

> --

> Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.mnot..net-252F-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C14f278ab3769469a44f908d59a16a2d6-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636584344383959765-26sdata-3DRXba2TyvYz6otecEHoLCT4tZ2I7EodxDiyPxWrn-252FnAw-253D-26reserved-3D0&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=ym7cE5rLl46aIfj8Q7KNEpy3FDfhyfumeXz9eQXmX1g&s=b_XyJvAQscNJNCwHmgj11ep8Xbsf7PvhDvONVZe3PR0&e=

>