Re: Getting to consensus on packet number encryption

Ted Hardie <ted.ietf@gmail.com> Tue, 01 May 2018 17:44 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F063412E8D7 for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWfwQgQjz4Im for <quic@ietfa.amsl.com>; Tue, 1 May 2018 10:44:15 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A904612E8D4 for <quic@ietf.org>; Tue, 1 May 2018 10:44:15 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id y15-v6so10671918oia.13 for <quic@ietf.org>; Tue, 01 May 2018 10:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmvh57zcYUEMjIbqo4l2C2VqrxYjl+NVVKffrggFwHU=; b=ujLFFW9hzfw4Odq3wYfUK7MOxyneoWjEG+vO5sRAP5j+ygF5GFFFPlFneR9u/ZIcxo ht9TXiQ0+AKCGAz1djvCt1gN5C5+pPMFUXsam7uWwVZw4x+eOCGiwKWEVIV+EYZ8h1ls 5PoCt35g19W9uC71F9TP5b9zw3WbQBA+fdthPRPwc4+s8QXZ6FUiecQEfAP1l4GEkfhQ yfdxVUdMJ7+87ipeaj6dE2nzM6QHYpQcH4PZsWuvWMPBmThHEacuWY+AsJnSDgMUdBsj 6rSJlmVaBdxbcVUDx5G8LTqc1tichKABG1fS7Xm+xBUjQFFLsQ0jv+jTTNEifMzGwRUn vwZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmvh57zcYUEMjIbqo4l2C2VqrxYjl+NVVKffrggFwHU=; b=jisSyF+etvuLFndcq/y/W7gfIjD4cQGRuTcKMDnaZoUKGGqWk4Agz2HPAVPBRLjKa+ TJEnfGw2Zty5zZwe/3Axt7ZGlRHE1CiE95OK5PoYFKjEBooFY5ZwSdloASe+A1Sc9L0p 0+LPYjQm7EjJmQkZRIPFMUNaBT99PulJ4Z8FDPC6jfAVDrtssvmD7SQI0AvfvZvd0dEx J3eBwZ4NJ5gofw73Qjm8HNPWLTX0lNaRXarHxn6ESjM8sF/GTG5CkIvz6d9N3Pt39uuY KZaMsg842+CX/2DW9BhR5HObNVXga8YXO4Ea7DIdkgD+yxHkbUt4XDvNfTKS2K1wio4d /Ccw==
X-Gm-Message-State: ALQs6tAcuFVGgl4CeTIi2nxhA+fPiCAzvatvX7+jw2GDnRhgFdwawo+t pvMGqJIoOLS03iIMUhV0ccxRRV/JpolKRatqKaE=
X-Google-Smtp-Source: AB8JxZpwXtzHBXfhHY8EPOaaSEkBJ/HISuB3wKejr63m+m6xIZH6umHhzRO+yWCn0Rq38K27wHs22MxMMFK8gV7HxA4=
X-Received: by 2002:aca:d6c4:: with SMTP id n187-v6mr9683616oig.284.1525196654868; Tue, 01 May 2018 10:44:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.67.153 with HTTP; Tue, 1 May 2018 10:43:44 -0700 (PDT)
In-Reply-To: <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch>
References: <CANatvzwCYrOZULG3iVmDFp97nr=M5=Gufo8TZjOGQVFUpsn0bQ@mail.gmail.com> <CAAedzxqDcPXJUE83KVnDiU23PvqDcTCrc6rRMw09FexjJA-Y6Q@mail.gmail.com> <CANatvzwjYE6EdvFtOXJMVQnutbVQ4YY+=XsQFzKwHzqWzZ4U+w@mail.gmail.com> <d32ade7b56bf4651952659307c08893b@usma1ex-dag1mb5.msg.corp.akamai.com> <CANatvzwHtCn8rLB8npf3i7PGyYZhVDRd2uojh5hv3uxtFPEsSA@mail.gmail.com> <58447D8E-782C-431C-8FC3-71124B10A047@trammell.ch> <CACpbDcdfF9w3qqrH1eB0sGU_4vheD9aMP5EXnp1o3Y19N19NUg@mail.gmail.com> <e8b4931a-3931-5b8d-8dad-3ca1939d5542@huitema.net> <CAKcm_gPaj3o-VTdA_0+Kk+nTcVJrYcs_BMyOiDGXKub3gB=GLg@mail.gmail.com> <MWHPR21MB063869878060E850137210FEB6820@MWHPR21MB0638.namprd21.prod.outlook.com> <20180501121906.GA5742@akamai.com> <F63059EA-BA14-4886-A4FB-AA5F04AC164B@akamai.com> <BY2PR15MB07757EAB6A818F1D8D8CCED9CD810@BY2PR15MB0775.namprd15.prod.outlook.com> <CA+9kkMCpxve3CKhQk45YKbvyOyQ6kvzyhpJhrTq1UM-QM+ms2Q@mail.gmail.com> <89893592-7135-4C24-BE1E-4B0FFD1A2E97@trammell.ch>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 01 May 2018 10:43:44 -0700
Message-ID: <CA+9kkMCUTRrM9SPEz=Q5GDgU7whryZ1cRdj-O3=GP=-vOr-X+A@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: Roberto Peon <fenix@fb.com>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d37fc4056b28848d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cSq-3NSoY0Fhypt-sjOaMe5Yel8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2018 17:44:19 -0000

On Tue, May 1, 2018 at 9:56 AM, Brian Trammell (IETF) <ietf@trammell.ch>
wrote:

> hi Ted, all,
>
> At this point I've pretty much come around to the opinion we should just
> land 1079 and discuss the rest, but this conversation continues to have me
> worried that we're coming to consensus on a feature we do not fully
> understand the applicability and limitations of.
>
> I also think that just landing 1079 and moving on is the right thing to do.


> PNE's primary utility is anti-ossification. While it reduces the amount of
> information available to an attacker attempting to achieve linkability of
> flows across a purposeful path migration, or with a single-PN-space
> multipath design, it does not eliminate it, so expecting more than a
> marginal privacy benefit from the feature per se is setting oneself up for
> disappointment.
>
> The reason to disable PNE in (admittedly ill-defined) "datacenter"
> environments is to trade off the (~1%ish) overhead for ossification
> protection you know you don't need because you didn't deploy anything that
> tries to abuse the packet number.
>
> (on which, more below; and on preview, what Praveen said)
>
> > On 1 May 2018, at 17:55, Ted Hardie <ted.ietf@gmail.com> wrote:
> >
> > On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <fenix@fb.com> 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  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.
>
> The "load-shifted to the next instance" example is an interesting one iff
> said load shifting causes the traffic that used to cross a private network
> to transit the open Internet instead.


Well, a long-haul link, certainly.  That may or may not be "the open
Internet" and the chances of it traversing a completely unknown middlebox
are low.  The chances of it passing by an unknown observer, on the other
hand, are not currently known but are presumed to be high.


> Is this a thing that ever happens in any of the environments that get
> called "datacenter" for networking technology purposes?
>
>
So, the way I look at this boils down to:

If the linkability or ossification concerns with packet numbers in the
clear are justified, you either need to have it on all the time or have
very clear methods for determining when the concerns are not present.  The
protocol is not aware of the l2 or l3 topology between an initiator and its
peer, much less the management of that path.

So the clear methods for determination really boil down to "someone turns
this off when they think it is right to do so".  Flows entirely within the
domain of control of a single provider might be a case where folks think it
is right to do so.  A subset of that domain of control is when the flow has
no long-haul links (for however you want to define that), the shorthand for
which is "datacenter network" (though it might well also be a small complex
of datacenters, an enterprise campus, or similar).  But the key is that you
believe that the topology between peer A and peer B has no middleboxes
outside of the shared domain of control that might ossify the behavior and
no observers whose use of this data concerns you.

If you control both peers and the network between them, using a QUIC
version where this is always turned off might make sense.  But having  QUIC
negotiate this outside of the version does not make sense to me, because
there is no way for an initiator or a responding peer to judge whether the
other side's assertion of safety is well-founded or even well-meant.  If it
has no independent data on this (and the protocol provides none), this
allows one side or the other to unilaterally turn off an anti-ossification
and anti-linkability feature for whatever gain it wants.  Since we're
trying to optimize for the long-term flexibility of the protocol, allowing
that particular point optimization seems contrary to our interests, much
less the privacy interests of the peers.

regards,

Ted


> Cheers,
>
> Brian
>
> > Ted
> >
> > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> >
> >
> > -------- Original message --------
> > From: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
> > Date: 5/1/18 5:25 AM (GMT-08:00)
> > To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>, Praveen
> Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
> > Cc: IETF QUIC WG <quic@ietf.org>
> > 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.
> >
> >
>
>