Re: Getting to consensus on packet number encryption

[Kazuho Oku <[e-mail]>]

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