Re: [ietf-privacy] Is there an official working definition for Privacy Online?

Nick Doty <npdoty@ischool.berkeley.edu> Fri, 06 May 2016 01:10 UTC

Return-Path: <npdoty@berkeley.edu>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7394212D6E5 for <ietf-privacy@ietfa.amsl.com>; Thu, 5 May 2016 18:10:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ischool-berkeley-edu.20150623.gappssmtp.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 YzMGO-Q97T1G for <ietf-privacy@ietfa.amsl.com>; Thu, 5 May 2016 18:10:14 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 5C56A12D6EA for <ietf-privacy@ietf.org>; Thu, 5 May 2016 18:10:11 -0700 (PDT)
Received: by mail-pa0-x22b.google.com with SMTP id r5so42648710pag.1 for <ietf-privacy@ietf.org>; Thu, 05 May 2016 18:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ischool-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=MDCfnS9bj1rezH8RS4rH48rmt82C5kmzasxbsiLZlYg=; b=OOO5vmaNkmCZnPYyJCHP7dzK8132c3GvSfmi9dj+qDept88j15RWAiyoNt7Ba5omFF qK0xzaf0Al2JHy678lwHZ55MJ7732/aMTqGYaXudZfbfjxXhO7NJeqv9bFeGe8nulJp/ ScAhlYgN/R7g0cq2lFGVbkwm4toDC3vwTMhT0lmF+lIEr/B5IGw08r7fjZw/Z1AXE7qs u0m8xKK/tc4ou/whVMFkg1Oy79ZrT1g8+Ot/6RHsjs+Yeme6qnOGF5Sf7F4cAuTKe6Eb 11QKb/cEXNtIRyl9mrgNkk5RPU7TUZCmSHCCvxZFPOH6NqLalWqnH9ZtNi8Vs8nMWPNk eqVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=MDCfnS9bj1rezH8RS4rH48rmt82C5kmzasxbsiLZlYg=; b=EfIdoN8l2KVxo2GcCrtYPMqgEyoWwY9GCp41hhr3KK0w3Ztya6+yjJICAng+BmAPpH Qn4Iwl0g6w+GP+5wkxApziCvZHOd9BTQb/uwFAEAYzRNfmZjmuMbTZzi7pzXvXTS7A9l 6sNz814Ljl2ssO98W/DHOyJiNcy5ksawYN8CEN7e92rGHT4r256gVm4NoI+VrM5essbu Wy3faMSZ/wfzN9DBmg5+RHGpCZ8y5xn23kRVMk33KjCosBUImzjEq3t0HojajgdTKfj5 bMNWT7ELoHG3/10QBZd20GN+tUlUL/StmbJ1z2autllXstdQSRYkUwow0/fzS2df/bdd dRxA==
X-Gm-Message-State: AOPr4FXtTdbrHF/Spc6aThzREEbnLDgfK+ViCOuzaheUBcOVgKTTBDg88o/uvQll2YrSYUsH
X-Received: by 10.67.10.205 with SMTP id ec13mr24900000pad.16.1462497011225; Thu, 05 May 2016 18:10:11 -0700 (PDT)
Received: from [192.168.1.129] (50-0-90-241.dsl.dynamic.fusionbroadband.com. [50.0.90.241]) by smtp.gmail.com with ESMTPSA id u2sm16376335pfi.26.2016.05.05.18.10.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 May 2016 18:10:10 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E330D332-6121-47D2-AAFD-BD6417CC7E4E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Nick Doty <npdoty@ischool.berkeley.edu>
In-Reply-To: <4826F2DD-7A3C-46ED-AB68-A1B1B1E5F30B@cooperw.in>
Date: Thu, 05 May 2016 18:10:05 -0700
Message-Id: <9E07A93C-E248-4630-8B01-E33667A0738A@ischool.berkeley.edu>
References: <552FCC84.6040305@gmail.com> <CA+9kkMCYuEGRidB1D=SGA0qxk+SuX6+HyqToYDmqQVmpBskWrw@mail.gmail.com> <5530329E.4060608@dcrocker.net> <01F784DA-5FD5-4D1F-8613-C2E668EDA765@isoc.org> <55311CE9.9040003@dcrocker.net> <DB3PR07MB138A042321BB99DF9AB94A4BCE30@DB3PR07MB138.eurprd07.prod.outlook.com> <55313140.9040400@dcrocker.net> <015a01d0798d$509954c0$f1cbfe40$@huitema.net> <CABtrr-X6CgN3J0dA1YBED0j6K7D5Mt2NAbUwGF5E67BoFX9JUQ@mail.gmail.com> <57268D25.3070708@dcrocker.net> <029801d1a4b9$c3b57850$4b2068f0$@huitema.net> <4826F2DD-7A3C-46ED-AB68-A1B1B1E5F30B@cooperw.in>
To: Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-privacy/_q6Y1Im5pSkvPP_X3FXX5feoAL0>
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, dcrocker@bbiw.net, Josh Howlett <Josh.Howlett@jisc.ac.uk>
Subject: Re: [ietf-privacy] Is there an official working definition for Privacy Online?
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 01:10:16 -0000

On May 5, 2016, at 7:53 AM, Alissa Cooper <alissa@cooperw.in> wrote:
>> On May 2, 2016, at 2:29 PM, Christian Huitema <huitema@huitema.net> wrote:
>> 
>> On Sunday, May 1, 2016 4:12 PM, Dave Crocker wrote:
>>> 
>>> If the term is to be a non-technical and vague reference, then let's stop
>> using it
>>> as if it were a technical term.  Philosophical, academic and social terms
>> are
>>> fine; the problem is when we use them as if they pertained to technical
>>> specifics.
>> 
>> Well, we do use the term "security" liberally, don't we? It is certainly
>> just as vague, but it is useful as a section header. It encourages protocol
>> designers to be concerned with the broad issue of security attacks. I think
>> that we have consensus that protocol designers should also be concerned with
>> the broad issue of privacy attacks.
> 
> +1. If people want to consider privacy as a heading under which we group a bunch of different kinds of attacks, that works perfectly well I think.
> 
> Rather than spending a lot of time to try to find a magical two-sentence definition that everyone can agree on (which I doubt is feasible), I think the time would be better spent on refining how we define the set of attacks and mitigations against them, building on or fixing what’s in RFC 6973, possibly turning bits of that into a BCP, etc. The two sentences will not be directly actionable no matter what they say, whereas a comprehensive threat model and mitigations suite could be.

+1. RFC 3552 doesn't provide a two-sentence definition of "security", but points out that the definition is not simple, but instead a common grouping of properties and threats, which get more detailed definitions in subsequent sections. Similarly, RFC 6973's terminology section does provide technical definitions of terms like unlinkability, fingerprinting, etc.

I do tend to agree with the conclusion that as a result we shouldn't be using "privacy" as a technical term on its own. Sentences in specs of the form "Feature X undermines privacy" or "Feature Y provides privacy to the end user" are either inappropriate, or more likely, incomplete. Instead: "Feature Y supports privacy by providing unlinkability of traffic between requests".

It might still be useful to refine a short definition that can be cited to speed up conversations on privacy at IETF or help in scoping work; NIST, for example, has been trying to come up with privacy engineering objectives analogous to the C-I-A triad for security.

Cheers,
Nick