Subject: [stir] draft-ietf-stir-problem-statement: Privacy requirements

From: Michael Procter <[email-masked]>
Date: Sun, 3 Nov 2013 17:31:33 -0800

In section 7, there is a privacy requirement to prevent 3rd parties
from learning what numbers have been called by a specific caller.
Should there be a similar requirement to prevent 3rd parties learning
what numbers have called a specific callee?

The reason I mention it is that there was an issue with an aspect of
vipr where a proposed mechanism could protect either the caller's
privacy or the callee's privacy but not both.  I'd like to avoid a
similar situation here.

Regards,

Michael

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 4 Nov 2013 15:20:34 +0000

I agree.

Jon Peterson
Neustar, Inc.

On 11/3/13 5:31 PM, "Michael Procter" <[email-masked]> wrote:

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

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 11:03:58 -0500

What third party?  The carrier? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Monday, November 04, 2013 10:21 AM
To: Michael Procter; [email-masked]
Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements

I agree.

Jon Peterson
Neustar, Inc.

---

From: Alex Bobotek <[email-masked]>
Date: Mon, 4 Nov 2013 11:23:10 -0800

What precisely is a 3rd party in the context of out-of-band validation?  A strict interpretation is that this is any party other than the caller and callee (or perhaps their carriers).  Other interpretations might be a party in the middle (e.g., able to access pcaps) who has no role other than perhaps packet transport.  

Such a strict interpretation pretty much rules out the use of public DNS or similar infrastructure as a store for any individual caller/callee PKI or policy; 3rd parties may be in the middle of requests.  A similar requirement would break some DKIM implementations.  

IMO, 
1.  3rd party needs to be more precisely defined and/or
2.  The degree of privacy compromise should be, at this stage, subject to design trades.   A "3rd-party" offering reputation/validation  services similar to a DNS service may have legitimate reasons to know one or more of caller/callee.  Perhaps the 'requirement' should be recast as a goal or requirement to minimize.  

Regards,

Alex

> Richard Shockey
> Sent: Monday, November 04, 2013 8:04 AM
> To: 'Peterson, Jon'; 'Michael Procter'; [email-masked]

---

From: Michael Procter <[email-masked]>
Date: Mon, 4 Nov 2013 11:49:04 -0800

At this stage, I am less concerned with the precise definition of what
constitutes a third party, and to what degree privacy is leaked.  I am
more concerned with ensuring that we seek to protect the called party
too, and not consider the calling party to be the only potential
subject of privacy leaks.

Michael

---

From: Alex Bobotek <[email-masked]>
Date: Mon, 4 Nov 2013 11:44:41 -0800

I believe we agree with the need for calling and called party privacy protection.  It's a good thing that this issue was raised.

But we have another issue; a requirement restricting 3rd party visibility that is ambiguous and/or overly strict.

Regards,

Alex

> From: Michael Procter [mailto:[email-masked]]
> Sent: Monday, November 04, 2013 11:49 AM
> To: Alex Bobotek
> Cc: Richard Shockey; Peterson, Jon; [email-masked]
> constitutes a third party, and to what degree privacy is leaked.  I am more
> concerned with ensuring that we seek to protect the called party too, and
> not consider the calling party to be the only potential subject of privacy leaks.
> 
> Michael
> 
> > What precisely is a 3rd party in the context of out-of-band validation?  A
> strict interpretation is that this is any party other than the caller and callee (or
> perhaps their carriers).  Other interpretations might be a party in the middle
> (e.g., able to access pcaps) who has no role other than perhaps packet
> transport.
> >
> > Such a strict interpretation pretty much rules out the use of public DNS or
> similar infrastructure as a store for any individual caller/callee PKI or policy;
> 3rd parties may be in the middle of requests.  A similar requirement would
> break some DKIM implementations.
> >
> > IMO,
> > 2.  The degree of privacy compromise should be, at this stage, subject to
> design trades.   A "3rd-party" offering reputation/validation  services similar
> to a DNS service may have legitimate reasons to know one or more of
> caller/callee.  Perhaps the 'requirement' should be recast as a goal or
> requirement to minimize.
> >
> > Regards,
> >
> > Alex
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Richard Shockey
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Peterson, Jon
> >> >Should there be a similar requirement to prevent 3rd parties
> >> >learning what numbers have called a specific callee?
> >> >

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 15:20:34 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alex
Bobotek
Sent: Monday, November 04, 2013 2:45 PM
To: Michael Procter
Cc: [email-masked]; Peterson, Jon; Richard Shockey
Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements

I believe we agree with the need for calling and called party privacy
protection.  It's a good thing that this issue was raised.
[RS> ] 
[RS> ]  Well I don't believe in Calling Party Privacy at all if, under the
proper cirmctances  there is violation of national laws such as fraud, abuse
and the violation of the called party's privacy and warrants are issued
under the appropriate review process. 

But we have another issue; a requirement restricting 3rd party visibility
that is ambiguous and/or overly strict.

[RS> ] 
[RS> ]  Exactly.. And a touch too politically correct for the current
environment.  So who is the third party?  Under what circumstances could
there actually be voluntary release of verbose metadata to third parties in
the interest of law enforcement. This is all very very slippery slope folks.
Michael given the nature of the problem statement whose privacy are you
trying to protect here. 

Regards,

Alex

> too, and not consider the calling party to be the only potential subject
of privacy leaks.
> strict interpretation is that this is any party other than the caller 
> and callee (or perhaps their carriers).  Other interpretations might 
> be a party in the middle (e.g., able to access pcaps) who has no role 
> other than perhaps packet transport.
> >
> similar infrastructure as a store for any individual caller/callee PKI 
> or policy; 3rd parties may be in the middle of requests.  A similar 
> requirement would break some DKIM implementations.
> >
> > IMO,
> > 1.  3rd party needs to be more precisely defined and/or 2.  The 
> > degree of privacy compromise should be, at this stage, subject to
> caller/callee.  Perhaps the 'requirement' should be recast as a goal 
> or requirement to minimize.
> >
> > Regards,
> >
> > Alex
> >
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Richard Shockey
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Peterson, Jon
> >> >In section 7, there is a privacy requirement to prevent 3rd 
> >> >parties from learning what numbers have been called by a specific
caller.
> >> >The reason I mention it is that there was an issue with an aspect 
> >> >of vipr where a proposed mechanism could protect either the 
> >> >caller's privacy or the callee's privacy but not both.  I'd like 
> >> >to avoid a similar situation here.
> >> >
> >> >Regards,
> >> >
> >> >Michael

---

From: Michael Procter <[email-masked]>
Date: Mon, 4 Nov 2013 12:41:26 -0800

> Michael given the nature of the problem statement whose privacy are you

I'm trying to protect the privacy of the called party.

Given the privacy problems discovered in vipr and given the number of
references to vipr and vipr-like technology in stir, I'd prefer to
avoid the situation where we end up with a design that involves
spraying messages like "I've just been called by a (debt collector|STD
clinic|divorce lawyer), how do I check it is really them?" to anyone
who happens to be participating in whatever distributed
hashtable/database/lookup function we end up picking.

Since the problem statement already offers a requirement for
protecting the calling party, I'd like to see a similar protection for
the called party.  Arguably, the called party should have a higher
level of privacy: they didn't choose to be called in the first place.
The alternative (having the called party essentially advertise their
incoming calls in order to be able to verify the identity) is hardly
likely to encourage widespread deployment of verification.

Michael

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 17:41:09 -0500

Yes thank you very much. That is my point exactly. 

It would be my preference that any reference to VIPR or iMessage or these
extraneous and specious existence proofs be completely removed from the
documents. They say nothing they offer nothing and VIPR as I have pointed
out several times was a total and complete failure as an IETF protocol. 

I completely agree with you the emphasis here is on the privacy of the
called party. That is the whole point of the exercise.  It's the call party
that need some for lack of a better word ..Reassurance.    Which is why I
wanted to start a thread on verbose CNAM as well. 

The methods of Track and Trace for the example you cite is out of our scope
but it has some relevance.  I'm aware of several T-DOS attacks against UK
based services.  We should be careful about what we try and require.  From
time to time we may want certain records exposed for perfectly ligimate
reasons. 

Nothing we do will protect us from the political class.   I live in Virginia
here the US and we have a Governor's race that is simply ... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Procter
Sent: Monday, November 04, 2013 3:41 PM
To: Richard Shockey
Cc: [email-masked]; Alex Bobotek; Peterson, Jon
Subject: Re: [stir] draft-ietf-stir-problem-statement: Privacy requirements

On 4 November 2013 12:20, Richard Shockey <[email-masked]> wrote:
> Michael given the nature of the problem statement whose privacy are 
> you trying to protect here.

Given the privacy problems discovered in vipr and given the number of
references to vipr and vipr-like technology in stir, I'd prefer to avoid the
situation where we end up with a design that involves spraying messages like
"I've just been called by a (debt collector|STD
clinic|divorce lawyer), how do I check it is really them?" to anyone
who happens to be participating in whatever distributed
hashtable/database/lookup function we end up picking.

Since the problem statement already offers a requirement for protecting the
calling party, I'd like to see a similar protection for the called party.
Arguably, the called party should have a higher level of privacy: they
didn't choose to be called in the first place.
The alternative (having the called party essentially advertise their
incoming calls in order to be able to verify the identity) is hardly likely
to encourage widespread deployment of verification.

Michael

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:20:36 +0000

On Nov 4, 2013, at 2:41 PM, Richard Shockey <[email-masked]> wrote:

> They say nothing they offer nothing and VIPR as I have pointed

Richard, respectfully, I don't think you have any clue or basis of information to say that. A fairly significant percentage of enterprise phones are ViPR enabled. I'd be willing to guess that I have a long list of IETF protocols that get less use and a short list of protocols that get more. iMessage which is very similar technology has even far broader deployment and impact. 

That said, I agree with Michael's comment that it is important to learn from the privacy issues in ViPR and make sure we get down requirements that turned out to be a late surprise in ViPR.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 5 Nov 2013 02:25:30 +0000

Cullen,

Enabled or capable? 
And percentage of deployments are we talking about? How about Cisco only?

Regards,

Martin

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 5 Nov 2013 02:31:11 +0000

> And percentage of deployments are we talking about? How about Cisco only?

I'm only know about Cisco numbers but I realize that other people have build ViPR system too.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 5 Nov 2013 02:32:29 +0000

There is a lot of code that never is used...

---

From: Dan York <[email-masked]>
Date: Tue, 5 Nov 2013 03:11:08 +0000

Michael,

>likely to encourage widespread deployment of verification.

+1.  I agree this is important and thank you for explaining a bit more.  I
didn't follow the first statements so the additional explanation helped.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/