Re: Getting to consensus on packet number encryption

[Gorry Fairhurst <[e-mail]>]

As I see it, adding PNE adds complexity, and presents risks for the 
protocol.

I accept there could also be a future be risk of ossification around any 
packet header - although as said also, the incentives for a middlebox 
doing odd things with a PN in QUIC would seem to me to be quite 
different from the incentives to mangle TCP (where you can easily 
influence the receiver state machine). As Mirja stated, this also leaves 
me skeptical about the benefits of PNE in avoiding ossification, nor the 
downsides of this. The direct linakbility appears from a decision to 
continue the PN sequence in the clear part of the header across a 
migration, not because a PN was visible.

While we are summarising: the majority of IETF transports have to date 
included some form of sequence number in all transport segements. This 
has often been usefully harnessed by tools such as wireshark or similar 
for measurement, debugging, and as a basis for more in depth analysis 
and operational tools. We have decades of experience with this way of 
working - although it seems to me that this list has not proven a useful 
place to discuss that.

I didn't see strong consensus on the value of PNE, so I understand that 
this is just something that has to be decided to move on. And I do wish 
to move on.

Gorry

On 02/05/2018, 14:04, Roni Even (A) wrote:
> Hi,
> I strongly support Mirja's view.  At least we can move forward.
>
> I did not feel from the discussion that the benefits from PNE vs the PN were meaningful enough to make me support any direction too many variables (Ossification, linkability, complexity and processing requirements, PNE not needed for all cases so negotiate,...) with no way for evaluation.  If there was a hum I would probably hum for "not enough information" or "no opinion" but still hope that some decision will be made.
>
>
> Roni Even
>
>
> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Mirja Kühlewind
> Sent: Wednesday, May 02, 2018 3:47 PM
> To: Benjamin Kaduk
> Cc: Praveen Balasubramanian; IETF QUIC WG
> Subject: Re: Getting to consensus on packet number encryption
>
> Hi Ben, hi all,
>
> at this point, I'm fine with moving on with a decision and I didn’t speak up recently because I did feel that just repeating my point of view over and over again (like other do) would bring the discussion forward but I have to say that I’m still skeptical about the benefits of PNE.
>
> I don’t think that it will help linkability as mitigation can be easy detected with simple traffic analysis (if you see both flows; if you don’t see both flows you can’t detect it no matter what) and I rate the risk of ossification on the packet number rather low (both in terms of the risk that it will happen and if even if it happens that it will hinder protocol evolution strongly) such that I simply don’t think that it is justified to spend ANY additional complexity on PNE.
>
> I might be wrong and I understand the fear of people about what can happen in a worst case scenario, however, I also learned during my time in the IEFT that complexity itself can be a barrier for deployment that should not be underestimated. If people don’t understand the specs we write, they will not be able to implement (and maintain) our protocols, or at least not be able to implement it correctly which might be even worse for deployment and security (than not using them at all).
>
> Independent of the decision on PNE, I would like people to please keep in mind that while increased security is preferable, it does not mean that this is a free ticket to add encryption wherever we can, even if there are no or maybe yet unknown benefits as it always comes with a cost.
>
> Mirja
>
>
>
>> Am 02.05.2018 um 14:10 schrieb Benjamin Kaduk<bkaduk=[e-mail]>:
>>
>> Hi Praveen,
>>
>> On Wed, May 02, 2018 at 02:02:37AM +0000, Praveen Balasubramanian wrote:
>>> We can get (1) done but I disagree that we can decouple (2). It doesn’t make sense to require performance overhead all the time with no benefit. For the Internet, PNE can prevent ossification so it is seen as a reasonable trade-off. For the datacenter, there is no known benefit, only cost.
>> Most of why I am pushing back so hard on this point is that I am
>> having a
>> *really* hard time getting the statement of "no benefit" (i.e.,
>> exactly zero) to mesh with my understanding of the situation.  I don't
>> know the best way past this impasse -- it doesn't really seem right
>> for me to make a list of potential benefits and have you shoot them
>> down, for example.  I think maybe you are trying to make a slightly
>> different point involving something like ongoing operational benefits
>> (as opposed to cost of implementation/risk of bugs/ecosystem
>> benefits), but I'm not entirely sure.
>>
>>> We know that there is a CPU cost, this is not speculation. Doesn’t
>>> matter if the cost is 1% or 10%. Hardware implementers have also
>>> raised concerns. Every
>> Well, I think it rather does matter for 1% vs. 10%.  If it was 0.1%
>> (unlikely, I suppose), then that might be "in the noise" and not worth
>> doing anything about, ever.  For a 1% cost, that's significant enough
>> to make me want to address it in my long-term plans, but it is not
>> necessarily a big enough impact to require immediate attention.  10%,
>> on the other hand, probably would require immediate attention and be a
>> show-stopper.
>>
>>> CPU cycle we spend on things that add no value to the user should be
>>> questioned. Every extra instruction we execute in the hot data path
>>> leaves less CPU for workloads, burns more power and makes for a worse
>>> comparison with HTTPS over TCP. The same argument as privacy holes
>>> holds here – just
>> The "burns more power" argument can be applied to every single CPU
>> instruction; relative measures (i.e., percentage of total CPU) from
>> actual deployment are what I find to be most compelling.
>>
>>> because there are some existing perf bottlenecks doesn’t mean we add
>>> more, particularly ones we cannot mitigate. I said it before that
>>> there are lots of ways we can improve UDP perf but I don’t know of
>>> any technique for reducing crypto CPU cost other than hardware offload.
>> And I ask again, who is "we"?  (At this point I am mostly assuming
>> "all QUIC implementors", but it would be nice to be sure.)
>>
>>> The cost is certainly worth saving with something as simple as a
>>> negotiation mechanism. Am I missing something about a transport
>>> parameter being
>>>  From the rest of the discussion, I don't think you've really sold
>>> people
>> on "certainly", yet.
>>
>>> complicated to implement? Implementations are free to support only
>>> PNE and not negotiate anything else. There is actually an even
>>> simpler mechanism if a transport parameter is deemed as costly: if
>>> the peer sends PN = 0 in the CI, then its requesting no PNE and the
>>> receiver can choose to proceed or drop and force TCP fall back. This
>>> should take only an extra if check on the receiver CI processing
>>> logic to implement. I am assuming here that PNE on input of 0 will not produce 0 so it’s a safe sentinel value.
>> I think some people are worried not just about the
>> complexity/simplicity of the mechanism implemented, but broader-scope
>> ecosystem and architecture issues, whether that's a general complexity
>> reduction initiative or more subtle issues involving middleboxes
>> attempting to coerce certain sorts of behavior.
>>
>> -Ben
>>