Re: [Potential Spoof] Re: Getting to consensus on packet number encryption

[Jana Iyengar <[e-mail]>]

I'll try to summarize my position on #1079. I see two points:
1. PNE will help against ossification and also, albeit to a limited extent,
linkability.
2. PNE has a CPU cost. While we can speculate, we still don't *know* what
this cost will be in the context of deployment, and whether this cost will
be the show-stopper. PNE's CPU cost may or may not be ameliorated by NIC
implementation. We should allow PNE negotiability when we have established
that this cost is worth saving.

My sense is that we agree on (1). This is what #1079 is doing, so we should
separate the two questions and get (1) done. Whether we do (2) or not is
being discussed on this thread, and I think we can continue, but #1079
should be independently submitted.

FWIW, I believe that we want to iterate on versions, and that we will want
to get a v2 out as soon as we have things to get deployed that left pending
in v1.


Thoughts on intra-DC QUIC, related to point (2) follow:

I don't think we'll reach a meaningful end to this discussion by getting
into security for intra-DC protocols. I understand that there may be
situations where one may have fair certainty about the deployment context
and given that the security tradeoff isn't the same as disabling TLS, the
bar will be substantially lower for disabling PNE.

On QUIC in intra-DC environments:
1. As Igor noted, the value of QUIC in the intra-DC environments is
uncertain, and I'm not yet sure that compromising on PNE for an unknown
cost in an uncertain deployment context is necessarily useful.
2. Separately, I remain unconvinced, based on my experience with trying to
get QUIC used for DC transport, that this cost is going to be an important
factor in QUIC adoption within DCs. I agree that CPU cost is a factor, but
there are much bigger things here that will need attention (segmentation
offload, smaller record sizes, userspace costs) that will dominate well
before this AES operation becomes a factor. This all remains speculation
though.

Praveen: Not making PNE optional right now does not mean we won't do it. It
just means that it's an open question. I'm not yet convinced that it's a
debilitating cost or one of the proverbial "million cuts" that will keep it
from getting deployed intra-DC. You are right that you'll want to
standardize PNE negotiation if you use multiple platforms, but surely you
will be just doing this between Windows systems for a while if you start
using QUIC inside the DC. That would be a great time to use versioning to
run your own version within the DC, and compare the cost to IETF v1, and
see if it is worth removing PNE. I hope you find other costs that are worth
eliminating or changes that are worth making to the protocol too, and that
they all become part of standard QUIC as a consequence. But in the
meanwhile, I don't see why making it optional is necessary right now to add
PNE at all.

On Tue, May 1, 2018 at 4:22 PM, Roberto Peon <[e-mail]> wrote:

> I’d suggest we start working on it now.
>
> This is only partly a joke ☺
>
> -=R
>
>
>
> *From: *QUIC <[e-mail]> on behalf of Roberto Peon <
> [e-mail]>
> *Date: *Tuesday, May 1, 2018 at 4:21 PM
> *To: *Praveen Balasubramanian <pravb=[e-mail]>, Ted
> Hardie <[e-mail]>
> *Cc: *"Salz, Rich" <[e-mail]>, Benjamin Kaduk <[e-mail]>,
> IETF QUIC WG <[e-mail]>
> *Subject: *[Potential Spoof] Re: Getting to consensus on packet number
> encryption
>
>
>
> Yup. I know.
>
> Prism was eye-opening partially because of the fact that the packets were
> not going across the internet, but rather within a secure network.
>
>
>
> I believe that ossification alone is a good enough reason to do PNE.
>
> The cherry for me is that it, along with other actions/mitigations, makes
> linkability more difficult for malicious actors.
> CRIME and related was eye-opening because it exposed the power of the
> observable side-channel.
>
>
> -=R
>
>
>
> *From: *QUIC <[e-mail]> on behalf of Praveen Balasubramanian
> <pravb=[e-mail]>
> *Date: *Tuesday, May 1, 2018 at 9:35 AM
> *To: *Ted Hardie <[e-mail]>, Roberto Peon <[e-mail]>
> *Cc: *"Salz, Rich" <[e-mail]>, Benjamin Kaduk <[e-mail]>,
> IETF QUIC WG <[e-mail]>
> *Subject: *RE: Getting to consensus on packet number encryption
>
>
>
> This is not about putting plaintext data on the network, this is about not
> adding PNE which is intended for preventing ossification. So I don’t
> understand what the trust issue being referred to is in case of the rare
> misconfig.
>
>
>
> Within a DC several things are different – the deployment may need
> different congestion control like DCTCP, different settings for various
> transport parameters (like minrto and max ACK delay), larger flow control
> window etc. This is true for TCP today. The out of box default uses the
> handshake RTT to make a determination of what’s intra-DC but there is rich
> configuration to override the default and set it based on 4-tuple filters.
>
>
>
> And there workloads like cloud storage and live migration that are by
> virtue of deployment intra-DC. These cannot be load shifted as they use
> private IP address space.
>
>
>
> *From:* Ted Hardie [mailto:[e-mail]]
> *Sent:* Tuesday, May 1, 2018 8:55 AM
> *To:* Roberto Peon <[e-mail]>
> *Cc:* Salz, Rich <[e-mail]>; Benjamin Kaduk <[e-mail]>;
> Praveen Balasubramanian <[e-mail]>; IETF QUIC WG <[e-mail]
> >
> *Subject:* Re: Getting to consensus on packet number encryption
>
>
>
> On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <[e-mail]> wrote:
>
> Also, Prism.
>
>
>
> -=R
>
>
>
>
>
>
>
> That's a little more succinct than I would be, but yes.  How does an
> application know that the flow it is initiating will traverse a topology
> that is deemed to be within a controlled environment?  You can say
> "configuration" but I fear it will turn up on a post-it
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fi.kinja-2Dimg.com-252Fgawker-2Dmedia-252Fimage-252Fupload-252Fs-2D-2DEdu6LPu9-2D-2D-252Fc-5Fscale-252Cf-5Fauto-252Cfl-5Fprogressive-252Cq-5F80-252Cw-5F800-252F194thbtyencs0jpg.jpg-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C4da44e8ac1df4708ad8808d5af7bfca8-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636607869411258976-26sdata-3DProlSHkbF2SgMH3qdQN-252BZFokXvsEBf-252F3o9MaUnil0g8-253D-26reserved-3D0&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=TuVfzypo-CZLo522lgMRrLpKxcFaHvW9kdNSI57lXT0&s=By2d_to7XzLEgAL3Or9cZc2Aykye-PZEenFQDviAUlw&e=>if
> you do.  Loads shift, resources move, and suddenly you find that host which
> used to be in the same rack, being down, has load-shifted to the next
> instance,  in a datacenter 500 miles away across a very different network.
>
> Many modern deployments are also in someone else's data center, so saying
> "Data center networks" doesn't say much about why you're trusting the
> network inside.
>
> Ted
>
>
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
>
>
>
>
> -------- Original message --------
>
> From: "Salz, Rich" <rsalz=[e-mail]>
>
> Date: 5/1/18 5:25 AM (GMT-08:00)
>
> To: Benjamin Kaduk <bkaduk=[e-mail]>, Praveen
> Balasubramanian <pravb=[e-mail]>
>
> Cc: IETF QUIC WG <[e-mail]>
>
> Subject: Re: Getting to consensus on packet number encryption
>
>
>
>     > I disagree that we need any more data for not doing PNE in the
> datacenter. Why would we add an extra encrypt-decrypt step for no obvious
> benefit?
>
> I am concerned that people will mis-interpret the meaning of a datacenter,
> and think that a bunch of servers, or even a rack, in an open colo space is
> a "datacenter."  Computers keep getting faster.
>
>
>