Re: Getting to consensus on packet number encryption

[Erik Kline <[e-mail]>]

Couldn't a middlebox have a policy where it permits QUIC sessions w/o
PNE but blocks sessions with PNE?  Then implementations would be
forced to choose how adapt: break altogether, maybe try TCP, or
disable PNE and carry on.

On 26 April 2018 at 01:22, Kazuho Oku <[e-mail]> wrote:
> 2018-04-26 9:21 GMT+09:00 Ian Swett <ianswett=[e-mail]>:
>> It has been, and I'm personally supportive of it, because I believe it'll be
>> useful for datacenter QUIC use cases.
>>
>> But the WG has to decide:
>>  1) Is it allowable to disable PNE?
>
> There are two concerns that PNE is trying to address: ossification and privacy.
>
> I won't mind if some portion of QUIC-like traffic has no mechanism to
> prevent ossification. This is because we can train the middleboxes to
> not ossify the PN field by having PNE in the majority of the traffic
> that they will see.
>
> OTOH, I would be worried of privacy implications. Once you define a
> protocol, it is hard to control how it is going to be used.
>
> But with that said, I think we might better wait to see if somebody
> still thinks he/she *needs* QUIC without PNE.
>
>>  2) What the mechanism is?  ie: Unilateral via TransportParams or negotiated
>> via an extension or ?
>>
>> On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop <[e-mail]> wrote:
>>>
>>> I think that’s been suggested before, though we’d need to sort out the
>>> details of what that looks like.  I don’t have a particular design in mind.
>>>
>>>
>>>
>>> From: Ian Swett [mailto:[e-mail]]
>>> Sent: Wednesday, April 25, 2018 12:57 PM
>>> To: Mike Bishop <[e-mail]>
>>> Cc: Christian Huitema <[e-mail]>; Deval, Manasi
>>> <[e-mail]>; Mark Nottingham <[e-mail]>; IETF QUIC WG
>>> <[e-mail]>
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>>
>>>
>>> Hi Mike,
>>>
>>>
>>>
>>> To clarify, are you suggesting adding a way to disable packet number
>>> encryption via negotiation in the v1 spec as well as adopting #1079?  Or
>>> would the choice of whether PNE is to be used unilateral, such as a
>>> transport param?
>>>
>>>
>>>
>>> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop <[e-mail]> wrote:
>>>
>>> Yes -- it seems that the biggest objection to #1079 was the difficulty in
>>> hardware implementation.  If we're hearing that hardware implementation is
>>> feasible at a reasonable cost, then I think we might have a winner.
>>>
>>> The CPU cost for a software implementation is still worth considering, and
>>> an option to not encrypt is probably reasonable to limit that burden for
>>> implementations / use cases that don't care.
>>>
>>> -----Original Message-----
>>> From: QUIC <[e-mail]> On Behalf Of Christian Huitema
>>> Sent: Wednesday, April 25, 2018 3:14 AM
>>> To: Deval, Manasi <[e-mail]>; Mark Nottingham
>>> <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>> On 4/23/2018 6:55 PM, Deval, Manasi wrote:
>>>
>>> > I had brought up the issue with PNE several weeks ago as a barrier to
>>> > hardware offload. After further review, it looks like a hardware offload can
>>> > implement the PNE at a small cost.
>>> >
>>> > The implementation can modify current HW crypto accelerators to support
>>> > encrypting a buffer in the first pass and then encrypting packet number in
>>> > the 2nd pass as already discussed on this thread. The exact requirement
>>> > (header checksum, packet length encoding) is still in flux so there may be
>>> > some small variations depending on the accelerator and final algorithm
>>> > chosen for PNE. Future offload designs can do more to further reduce the
>>> > overhead.
>>>
>>> Thanks for the information, Manasi. I have modified the wiki page
>>> describing the PNE issues and alternatives to reflect this new data:
>>>
>>> https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives..
>>> With that new information, it appears that PR #1079 is superior to every
>>> other alternative.
>>>
>>> -- Christian Huitema
>
>
>
> --
> Kazuho Oku
>