Re: [Spud] Thoughts on the privacy concerns expressed at the BoF

Kyle Rose <krose@krose.org> Wed, 27 July 2016 14:41 UTC

Return-Path: <krose@krose.org>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB112D914 for <spud@ietfa.amsl.com>; Wed, 27 Jul 2016 07:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 ympEFofCtr_8 for <spud@ietfa.amsl.com>; Wed, 27 Jul 2016 07:41:57 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 83F5712D913 for <spud@ietf.org>; Wed, 27 Jul 2016 07:41:57 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id x25so30896349qtx.2 for <spud@ietf.org>; Wed, 27 Jul 2016 07:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G9b2SIkzt80kGYC1oVKAz2vDn0wNhXzaOeYUu8kstI0=; b=YoE3ko+Ab4asoU1EJu65yNq//ahbs1OplWwNIBPKKjATLZYAxX4+WY26dzBSt/LRdv Xt5TGSDFL89iHaQezvAUR5M2/d/hGD58MJIEr/hP8UjjeD8ThZ1kRmE0EBC8NbFeFuua POOpbO9FvprZcExpBZXNowJqx8yaNNfH8BJno=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G9b2SIkzt80kGYC1oVKAz2vDn0wNhXzaOeYUu8kstI0=; b=N6yt5UeXpvwnTHCBoaOmKn+64V2iB3kNbssYHx9VXL5T0xAfjSsLKRGawmkmbqTZtf m4YlQl1lYZXUdv5UpjTeUZa2tnFKNEj7CAGDmaO8udaHpYIaP0k2RTvFvOICR+rL923o 5VGYhKsXX7jlDT1A65Rev9hBVDtQhwSf5r87GrselPNBsFB6wrfrDr23KuTO921Lawr4 A82OoZMrgNWMv86ohPXsCgbGJwjE/xqLk7Zw1c+J9tChQbgk7Ypno7m5sXO6NsF0uSH2 4eHog0uBv2s9g7FvROiw0RyhK32I4xeQjMniTYEpGpr3hzzJUFVRxaH4a6I+M5y8d0Gv vtUA==
X-Gm-Message-State: AEkooutY9+DvCcQMKzfTNp7ojgdPM86pWTYlF1WJTupD26eBPTil38u78kMSFZj9SqDuTS7rGbJ5E5vZNUDEog==
X-Received: by 10.237.36.38 with SMTP id r35mr49676663qtc.3.1469630516533; Wed, 27 Jul 2016 07:41:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.94.70 with HTTP; Wed, 27 Jul 2016 07:41:55 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <CA+9kkMDNfFPPJxDuDubcdsvTuNqT3K7qZK4o7TB5-7wHaroONQ@mail.gmail.com>
References: <CAJU8_nUDZnYuN0RHHyw0CCoK47mdpJV2OkZTGVeNBa-0p1R0KA@mail.gmail.com> <CA+9kkMDNfFPPJxDuDubcdsvTuNqT3K7qZK4o7TB5-7wHaroONQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 27 Jul 2016 10:41:55 -0400
Message-ID: <CAJU8_nX9y9nWbDMgvHOZXhJPUz70-eiCW3nbkEChLffRx4Qxag@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a113d3aace3f53c05389f0413
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/CBIEjNpAeNyRHd1w4ve8O_v44bI>
Cc: "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] Thoughts on the privacy concerns expressed at the BoF
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2016 14:42:00 -0000

(Forgot to respond to all.)

On Mon, Jul 25, 2016 at 12:18 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> Again, as Brian pointed out, we are not talking about field lengths here
> that could serve this identifying function by themselves  we are talking
> about field lengths sufficient for expressing a small number of signals to
> the path.
>

I think part of my hesitation results from my inability to think of any way
to express this in a meaningful way in the charter. The draft charter says:

q( Endpoint verification of signaling integrity, careful design of minimal
data structures, and restrictive policies for registration of signals can
help to meet this goal. )

and refers to Mirja's use cases document, but provides no explicit guidance
around what "minimal" means in an absolute sense, not with respect to an
individual use case . And I'm not sure it can or should get any more
specific (it is a charter, after all, not a technical draft or protocol
proposal), which leads to a dilemma: by not being more explicitly limiting
about total information per packet, are we setting ourselves up for a
situation in which the WG subordinates privacy to other goals and produces
and successfully deploys something too expressive, some time after which
users and governments end up in a game of chicken (idiom: driving two cars
toward each other at high speed, with the first driver to veer off the
loser) when some government bets that access to content is worth more than
the end-to-end integrity protection mandated by PLUS, leading it to
hijacking a valid PLUS field without endpoint cooperation, essentially
telling users "If you want access, you need to turn off integrity
protection"? Seems far-fetched now, but it takes only a critical mass of
impairment before users are required to comply just to interoperate: it
doesn't even have to result from laws in one's own country.

Pretty sure this shouldn't be addressed in the charter as a specific number
of bits, but I think you'd resolve a lot of fears of abuse by somehow
constraining the field space and the number of fields per-packet. (The
amount of data implied by "In-Band Measurement" jumped out at me as
problematic, for example.) And yeah, I get that this directly implies
additional potential for ossification. There are a huge number of tradeoffs
here, and there's no way to know we've made the right ones until long after
the decision has been made, but can we look at the proposed use cases and
decide which need to coexist in a single packet, and which maybe expose too
much space?

The other side of this (what can PLUS do *for* privacy?) I'll address in my
response to Mirja.

Kyle