Re: Getting to consensus on packet number encryption

[Kazuho Oku <[e-mail]>]

2018-04-27 1:51 GMT+09:00 Lubashev, Igor <[e-mail]>:
>> if some middleboxes decide to pass QUIC without PNE but block QUIC with PNE, we might be incentivized to use QUIC without PNE.
>
> If a middlebox really dislikes PNE, it can just block QUIC altogether, forcing a TCP fallback.  Is TCP better than QUIC-without-PNE from any POV in that situation?  (And if so, this should be the recommendation to QUIC stacks with negotiable PNE -- fallback to TCP, if path is blocking PNE.)

The argument here is that if we define PNE as an option turned on by
default and see some middleboxes blocking PNE, we might be
incentivized to turn off PNE for *all* connections, because detecting
blockade and then falling back to a less secure protocol is hard and
time consuming.

> - Igor
>
> -----Original Message-----
> From: Kazuho Oku [mailto:[e-mail]]
> Sent: Wednesday, April 25, 2018 10:25 PM
> To: Erik Kline <[e-mail]>
> Cc: Mark Nottingham <[e-mail]>; Mike Bishop <[e-mail]>; Ian Swett <ianswett=[e-mail]>; Christian Huitema <[e-mail]>; IETF QUIC WG <[e-mail]>; Deval, Manasi <[e-mail]>
> Subject: Re: Getting to consensus on packet number encryption
>
> 2018-04-26 10:46 GMT+09:00 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.
>
> There are two ways of negotiating the use (or non-use) of PNE. One is use Transport Parameters and the other is to use a different QUIC version.
>
> Use of Transport Parameters is secure because it is part of the TLS handshake. Version negotiation has it's own protection against downgrade (or upgrade) attacks (see https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.4.4).
>
> So I would assume that a middlebox trying to intervene in the negotiation of PNE use can be detected.
>
> That said, I do see your point that if some middleboxes decide to pass QUIC without PNE but block QUIC with PNE, we might be incentivized to use QUIC without PNE. In such case, we might end up having privacy leaks & ossification.
>
> I think that is a good argument for always having PNE turned 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
>>>
>
>
>
> --
> Kazuho Oku
>



-- 
Kazuho Oku