Subject: RE: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 18:39:54 -0600

A few comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 4:24 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
> Subject: Re: [Sip] Comment, SIP Privacy draft
> 
> 
> > significantly limited in the process. For example, I'm not aware of the
> > motivation to allow proxies to add Call-Info, and on initial reflection
that
> > doesn't seem indispensible. I have not exactly found the proponents of
RPID
> > to be similarly accomodating.
> 
> This can be very useful for my incoming proxy: You call me, my proxy
> looks up your web page or other similar information in a database,
> network information repository, etc. This is then presented to the
> (embedded) end system with your call. Usual caveats about trusting the
> information apply. Why should this functionality be ruled out?
> 

Well, at the very least it has some privacy concerns, as you suggest below.
The proposal on the table is apparently to overload Call-Info to allow
proxies to share your identity amongst themselves as an alternative to
standardizing the RPID header. I think overloading the Call-Info header for
this purpose should be discouraged; I don't have any strong intuition about
the best way to discourage it.

> Short of disallowing users or proxies to insert any information in SDP
> (for users) or SIP headers, there is no way you can keep any proxy from
> inserting whatever they want. If this information is public, not much to
> object to. If my carrier or other party releases private information to
> a third party, including the request destination, without my consent
> this is presumably a breach of contract or a breach of law, depending on
> the jurisdiction. (In Europe, it would be an actionable offense.) We can
> help "good guys" do the right thing, by indicating our privacy desires.
> We can't keep bad guys from leaking information they have access to.
> 

Agreed that all we can do here in the SIP WG is not standardize bad designs.
Definitely agreed that the mechanism by which a user expresses privacy
preferences should apply to headers like the Call-Info, and that we have to
acknowledge that service providers acting in bad faith can and will
disregard these preferences.

> Also, email has a long tradition of inserting information without
> explicit user consent, for example, X-Authentication-Warning.
> 
> I think we should be careful of trying to over-engineer what's primarily
> a social or legal problem.

I'll grant that over-engineering here is a risk. I'm just saying that we
shouldn't push the problem of network-verified identity into the Call-Info
header; this would not create any additional leverage on the problem (other
than the perception, apparently, that this can be finalized without the
consent of the SIP WG).

> Henning

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Mar 2002 20:35:42 -0500

> Well, at the very least it has some privacy concerns, as you suggest below.

I don't think we disagree, but just to clarify:

There are no privacy concerns if a proxy under my control inserts
information it has access to, as long as this proxy is not doing a
black-bag job getting this information. If you call me, I have every
right to find out whatever is legal to find out about you and have my
proxy insert this information in any way it sees fit. I don't think it
helps the precision of the argument if we conflate everything into
"privacy".

The privacy concern is that if a third party, neither caller nor callee,
has access to privileged information and inserts this without the
consent of the owner of the information. As to what information is
allowed to be inserted or not is a matter of law, contract and custom,
not technology. As a trivial example, for an 800#-call, the calling
number will be inserted and made visible to the callee regardless of
whether the caller likes that feature or not. The caller's only choice
is not to make the call or pay with his own dime.

> the best way to discourage it.

I agree that overloading is harmful, particularly if the trust and
control semantics are different. Call-Info and Alert-Info have no
in-band trust indication or notion as to who can and should insert or
remove it. I find this distinction more important than the difference
between a name and a URL.

> disregard these preferences.

If Call-Info (and maybe other headers) are inserted by the caller, the
issue is "can you trust the information?". If it's inserted by a proxy,
the issue is also "is the proxy allowed to do that, legally speaking?".

In general, I could see a need for, say, a caller-preferences indication
that would say "don't route my call where my identity is likely to be
revealed". Indeed, caller-preferences may well have suitable mechanism
(preference vs. don't-make-the-call-if-you-can't-oblige) already in
place, only needing the appropriate labels.

The practical problem with any such policy is that it is, well, policy.
I'd be worried about granularity and expressiveness ("Call-Info is ok,
but only if the call isn't routed to a foreign country with nasty local
intelligence services").

> than the perception, apparently, that this can be finalized without the

While I'm not disagreeing with your specific sentiment, I can sympathize
with the frustration of the authors of the "privacy" draft. I would feel
better if we could get away from intent and such, and focus on who
inserts what information where, making sure that the recipient of the
information has enough data to judge the trustworthiness (or knows that
this is always untrustworthy). As long as information doesn't make false
pretenses and misleads implementors and users, intent is just a bit too
much beyond engineering. I think attempts to align any differences
between promises and reality in the draft, as already happening with
wording suggestions regarding "privacy", are more helpful.

Henning

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 30 Mar 2002 12:11:30 +0000

At 8:35 pm -0500 29/3/02, Henning Schulzrinne wrote:
>As a trivial example, for an 800#-call, the calling
To which I reply::
Hi Henning, Folks,
   I'm not sure this is correct everywhere.
I can make a call to an 0800 number in the U.K. whilst selecting CLIR.
Result:: The call center doesn't get my CLI (even though it's used in
the free phone service).

Equally, due to a particular definition of competition used over
here, the CLI may not be passed between TSPs.

Finally it is common over here to not present the CLI when a call
originates from a PBX (it can be a devil of a job to get the TSP
to even present the pilot number).

Thus, at least in the U.K., the CLI may be present within a TSP's
network, but they may not pass it onwards, or the presentation is
suppressed by default.

I'm not comfortable with the suggestion that a provider can present
data that they have to hand to the destination party. I suspect that
this will entertain the regulator for at least a second, prior to the
realization that they will have to fill in some paperwork.
Note that "the regulator" here need have nothing to do with telecomms -
this can be seen as a data protection issue, so affecting data transfer
at least across Europe (and to companies that have self-certified the
"safe harbour" data protection agreement in the US).

Yes, this is NOT the PSTN; yes, I don't want it to be the PSTN; no, it's
not technically possible to stop a "bad-faith" intermediary inserting
data that as a caller I believe is private; yes, you may WELL find that
things work differently outside the US, and finally, yes, in practice
there may be a regulatory regime, if only to deal with data protection.

Whether this needs anything *within SIP* other than mandatory requirement
to carry a caller's privacy preference and to allow a hashed ID that can
be recovered on appropriate grounds, I'm not sure. The 0800 example is,
however, limited.

all the best,
    Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>: