Subject: [perpass] draft-bray-privacy-choices-00.html

From: Tim Bray <[email-masked]>
Date: Sat, 14 Mar 2015 09:52:52 +1300

This was about to expire so I was going to refresh it but uploader is
closed of course.  See
https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html

Just a reminder that if this group wants to do anything in this space, my
editorial services are available.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Mar 2015 21:28:02 +0000

Folks,

> editorial services are available.

I'd be interested in opinions as to how/whether we ought process
this.

Ta,
S.

> 
> 
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Mar 2015 17:51:50 -0400

Hey,

As the draft stands now, it needs more detail and contributions to be helpful.  If folks are interested, please contribute.

IMO, It would have to be broken down further in terms of the types of encryption and cost/benefits.  

For instance, KMIP (yes, I know this is not an IETF standard) is on an upswing.  So is the general statement on cost of PKI specific to transport encryption?  How does OS factor into this and help with the cost/benefit?  We should know more soon through efforts like Let's Encrypt and Fedora having IPsec unauthenticated tunnel mode on by default (I think in version 23).

What requests are SPs getting in regard to encryption (transport, application data or data at rest) and what are the hurdles?  

Operators may not be hanging out on this list, so maybe a post with the types if info you are looking for to build this out should go to opsawg with a pointer to the list you think this should be discussed on.

Thanks,
Kathleen 

Sent from my iPhone

> On Mar 13, 2015, at 5:28 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Folks,
>

---

From: Tim Bray <[email-masked]>
Date: Sat, 14 Mar 2015 22:27:24 +1300

I certainly agree that any draft-*-00 almost certainly needs heavy doses of
IETF input.  But I’m actually failing to understand where Kathleen’s
suggestions are trying to go.  This draft is trying to make general points
that are orthogonal to any particular technology, including:

- Positive & negative privacy failures are asymmetrically harmful
- the right choices are hard to make, so just don't ask inexpert uses to
make them,
- the cost of privacy technologies is monotonically falling

I think this draft is most useful if it can restrict itself to saying
things that are widely true across the tech-trade-off spectrum.  So, while
transport encryption is one of the most widely-used privacy technologies,
the points above are also true (I think) when applied to entirely different
things like message signing and server-side encryption-at-rest.

Sorry, I’m entirely failing to think of what this draft might say about OS.
The admirable Let’s Encrypt work is I guess evidence of the
monotonically-decreasing-cost premise.

SPs are being asked to deploy a variety of privacy technologies,and I’ve
observed recurring patterns of muddy thinking in their pushbacks; this
draft is an attempt to curate the arguments that are useful in these
discussions, independent of any particular flavor of privacy technology.

On Sat, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Hey,
>
> As the draft stands now, it needs more detail and contributions to be
> helpful.  If folks are interested, please contribute.
>
> For instance, KMIP (yes, I know this is not an IETF standard) is on an
> upswing.  So is the general statement on cost of PKI specific to transport
> encryption?  How does OS factor into this and help with the cost/benefit?
> We should know more soon through efforts like Let's Encrypt and Fedora
> having IPsec unauthenticated tunnel mode on by default (I think in version
> 23).
>
> What requests are SPs getting in regard to encryption (transport,
> application data or data at rest) and what are the hurdles?
>
> Operators may not be hanging out on this list, so maybe a post with the
> types if info you are looking for to build this out should go to opsawg
> with a pointer to the list you think this should be discussed on.
>
> Thanks,
> Kathleen
>
> Sent from my iPhone
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 14 Mar 2015 07:27:29 -0400

Hi Tim,

Sent from my iPhone

> On Mar 14, 2015, at 5:27 AM, Tim Bray <[email-masked]> wrote:
> 
> I certainly agree that any draft-*-00 almost certainly needs heavy doses of IETF input.  But I’m actually failing to understand where Kathleen’s suggestions are trying to go.  This draft is trying to make general points that are orthogonal to any particular technology, including: 
> 
> - the right choices are hard to make, so just don't ask inexpert uses to make them,
> I think this draft is most useful if it can restrict itself to saying things that are widely true across the tech-trade-off spectrum.  So, while transport encryption is one of the most widely-used privacy technologies, the points above are also true (I think) when applied to entirely different things like message signing and server-side encryption-at-rest.  
> 
> Sorry, I’m entirely failing to think of what this draft might say about OS. The admirable Let’s Encrypt work is I guess evidence of the monotonically-decreasing-cost premise.
> 
> SPs are being asked to deploy a variety of privacy technologies,and I’ve observed recurring patterns of muddy thinking in their pushbacks; this draft is an attempt to curate the arguments that are useful in these discussions, independent of any particular flavor of privacy technology.

Ok, fair enough.  I think some more text is needed to make your points clear as it wasn't enough for me to see the direction you were heading.

Thanks,
Kathleen 
> 
>> On Sat, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty <[email-masked]> wrote:
>> Hey,
>> 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: Robin Wilton <[email-masked]>
Date: Sat, 14 Mar 2015 13:35:42 +0000

I think this is an important and useful topic. And as Tim notes, I think it's worth getting to a very clear statement of the problem and associated factors, before getting to the level of technology-specific detail suggested by Kathleen (though I agree that that level of technical detail should be one of the destinations towards which this document moves us).

My main gripe is with the label "privacy protection" as applied to the issues Tim raises. I think the problem statements are good, but I think they are problems of confidentiality, not privacy.

To try to illustrate why, I suggest the following scenario: 

Primrose goes to InsureMe.com, where she will be asked for a lot of personal data. InsureMe.com invites her to register and create a new account, with an ID and password; all this is done over https, so InsureMe.com is confident it has taken suitable steps to protect the data from being visible to third parties. Thereafter. Whenever Primrose returns to the site, she is asked to log in before she can access any of her personal data.

So far, this is all consistent with the requirements in Tim's paper. However, InsureMe.com also has a B2B relationship with Gotcher.com, a targeted advertising service. InsureMe.com shares Primrose's data (and that of all its other account holders) with Gotcher.com, but when doing so it always makes the Gotcher folks log in to a data server, and the data passes over an encrypted session. 

I Primrose hasn't consented to this, her privacy has been violated - but I'm not sure we've broken any of the principles Tim sets out. I think InsureMe.com has put some confidentiality measures in place, between itself and Primrose, and itself and Gotcher.com, but those have not protected Primrose's privacy.

I think there are two options:

1 - re-label the problem as one of confidentiality, not privacy, in which case the document is already a good basis for further discussion;

2 - keep the "privacy protection" label, in which case the document needs to build on the existing confidentiality topic, but set it in the context of the broader privacy problem, and explain what confidentiality services contribute towards solving it.

I think both options would take us somewhere useful, because users' confidentiality and privacy are *both* affected by the asymmetries and market dynamics Tim describes.

Hope this helps,
Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Mar 2015 08:00:09 -0700

On 3/14/2015 2:27 AM, Tim Bray wrote:
> This draft is trying to make general points that are orthogonal to any
> particular technology, including: 
> 

+1 to the nature and direction of this document.

Especially for topics that are complex, poorly understood and/or are
controversial, it can greatly help to discuss issues and tradeoffs in
higher-level, non-technical terms.  I usually cast this as needing
statement about functional benefits and detriments for users (end-users,
operators, etc.)

The summary bullets Tim provided, above, are worth adding to the
document early, with the rest of document providing substance to them.

If there is enough community difficulty in readily seeing the nature and
benefit of this exercise -- I usually assume that when any one
reasonable reader has that sort of problem, others will too -- we should
probably find an example to add that distinguishes between this level of
discussion and the lower-level type that IETF work typical deals with --
and that ought to derive from these higher-level points.

There might be an line of discussion to add to the document, namely
tradeoffs and limitations of various technical approaches, especially
popular ones.  For example, transport-level encryption has notable
benefits, but the deficiencies seem to be absent from most IETF
discussions, leaving very large holes in the creator/consumer path.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Bray <[email-masked]>
Date: Sun, 15 Mar 2015 10:14:29 +1300

OK, I’ll go ahead and do an -01 with a better introduction, which is
clearly needed.    Interested to hear what others think of Robin’s
privacy/confidentiality distinction.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Mar 2015 10:22:29 -0400

Robin,
> ...
>
> Primrose goes to InsureMe.com, where she will be asked for a lot of personal data. InsureMe.com invites her to register and create a new account, with an ID and password; all this is done over https, so InsureMe.com is confident it has taken suitable steps to protect the data from being visible to third parties.
Third parties on the wire. Experience shows that Primrose's data is most 
likely to be
disclosed to third parties once it is on the InsureMe.com web site. Your 
example
goes on to cite a privacy violation in the form of Gotcher.com. But, a 
successful attack
against InsureMe.com also would violate the confidentiality of 
Primrose's data.

Bottom line: I agree with your observation that privacy is not the same as
confidentiality, and we often overly simplify these discussions.

Steve

---

From: Robin Wilton <[email-masked]>
Date: Mon, 16 Mar 2015 14:45:47 +0000

Hi Steve - and thanks for the correction.

I agree with your additional use-cases/threat scenarios, naturally… I was just trying to keep it to one simple illustration ;^)

R

On 16 Mar 2015, at 14:22, Stephen Kent <[email-masked]> wrote:

> Third parties on the wire. Experience shows that Primrose's data is most likely to be
> disclosed to third parties once it is on the InsureMe.com web site. Your example
> goes on to cite a privacy violation in the form of Gotcher.com. But, a successful attack
> against InsureMe.com also would violate the confidentiality of Primrose's data.
>