Re: Getting to consensus on packet number encryption

[Jana Iyengar <[e-mail]>]

I agree that negotiating PNE runs the risk of having two types of
connections on the Internet. I agree that the risk of blockage doesn't seem
high, but honestly, having seen how middlebox features get deployed, I'm
not convinced that it won't happen (though I suspect it's unlikely to
happen at a large scale). I understand the desire to have it off within DCs
though, so I'm sensitive to that need.

I'd like to hear more about why making PNE optional isn't a decision that
we can punt to later though. I'd like to move along with PNE now, and come
back to negotiating this as an option once we have some deployment
work/experience in intra DC environments. I'm not yet convinced that this
is going to be your biggest cost in an intra-DC environment, and if it is,
then we can surely revisit this decision and add a param later to make PNE
optional, either later in v1 or in v2. We are talking about a very narrow
view into total cost at this point -- this one AES op is unlikely to be the
bottleneck. But I have no data, and I don't think anyone has any full
deployment experience yet.

TL;DR: I'd like to suggest that we move ahead with PR #1079, and continue
discussion on adding optional PNE in Issue #1296.

Brian: You're right that a middlebox must serve some perceived function to
see deployment. The problem is that the value and cost of any deployed
function however is also perceived, and everyone has different perceptions.


On Fri, Apr 27, 2018 at 10:20 AM, Brian Trammell (IETF) <[e-mail]>
wrote:

> Hi, all,
>
> I am deeply skeptical of the possible existence of a box that would permit
> QUIC with unencrypted PN, but not with encrypted PN. The PN is simply not
> valuable enough to the path on its own to do the design work to detect and
> interfere with that case. Better in that case just to block QUIC and force
> TCP fallback.
>
> Again, I would like to encourage everyone to consider that a middlebox
> must serve some perceived function to see deployment.
>
> That said, it seems like we have a way forward for
> not-terrible-for-offload PNE, with negotiation to shut it off in controlled
> environments where one wants to shave energy expenditure. +1 to Praveen’s
> suggestion to add transport parameters to the standard for this for
> purposes of interoperability..
>
> Cheers, Brian
>
>
>
> Sent from my iPhone
>
> > On 27 Apr 2018, at 08:38, Kazuho Oku <[e-mail]> wrote:
> >
> > 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=40google.com@dmarc.
> ietf...org>:
> >>>>> 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
> >
>
>