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

From: "Mark Watson"<[email-masked]>
Date: Thu, 11 Apr 2002 16:28:39 +0100

Just on this one issue of obfuscation of the From/To field....

Let's be really clear about why this has come about:

Some Service Providers *believe* in the following proposition:

(*) IF the UA is allowed to put identity information into From/To, THEN the
Service Provider will be forced (by Data Protection) to provide services
which modify these fields, in order to protect the privacy of people other
than the actual calling user - subscriber, forwarding etc.

First, set aside the question of whether to agree with (*) or not.

There are three options for people with this belief:
1) *Require* permanantly that the UA does not put identity information into
From/To
2) Reject requests where the UA puts identity information in From/To if
privacy is required
3) Build network services which provide the necessary modification
(+whatever else is needed)

I do not think there are any other options.

We all agree that (1) is bad. (2) looks attractive but is not backwards
compatible, requires a double request (not good for wireless) & has issues
as to whether you trust the UA (in redirection scenarios).

I was looking for a consensus that (3) is a possible and valid thing to do
for these Service Providers. If the IETF SIP group agree that (3) and not
(1) is _a_ valid solution to this problem, then there is more chance of
other fora adopting (3) instead of (1).

So far, people have been arguing against the belief (*). The question is not
whether (*) is demonstrably true but whether there is sufficient *chance* of
it being true to justify serious consideration. A significant group of
Service Providers obviously think it is - they are worried they will be in
this situation and want a solution defined - that should be enough for us to
discuss solutions.

So, can we agree to recommend at least that people with belief (*) adopt
solution (3) and not solution (1) ?

...Mark

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 11 April 2002 08:28
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: [email-masked]; Ben Campbell; Flemming Andreasen; Peterson, Jon;
> 'William Marshall'
> Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft
> 
> 
> 
> 
> Mark Watson wrote:
> > 
> > All,
> > 
> > I feel profoundly lucky that yesterday and Friday were 
> public holidays
> > in the UK :-)
> > 
> > Perhaps I can take advantage of this vantage point to offer 
> a summary of
> > the thread. Protagonists please speak up if I have 
> mis-represented you
> > below, but please don't re-open old fronts.
> 
> Thanks for the summary. It is well needed. I suspect much of 
> the lack of
> comment derives from the difficulty in following this long thread.
> 
> I would kindly request all participants to please keep the discussions
> technical. A lot of the emails in this thread were personal attacks.
> Many more were threats along the general line of "do X or 
> standards body
> Y will do Z". I really hate the latter ones. Let us hear no more of
> either type of nonsense. It is not the IETF way.
> 
> > 
> > 1) Call-Info
> > 
> > Long arguments about the alledged similarities/differences between
> > Call-Info and RPID. Suffice to say that the point has been made that
> > Call-Info (and perhaps other things) could be abused to do 
> the things
> > that RPID does, and in particular to do the 'Bad Things' 
> that some are
> > worried about with RPID. The point of disagreement was 
> whether in the
> > case of Call-Info, this would be 'major abuse', with RPID 
> was set up to
> > make these 'Bad Things' easy, or whether there was some equivalence.
> > 
> > The key point is that this kind of abuse of Call-Info may 
> happen if we
> > do not provide an alternative.
> 
> It was never our intent for Call-Info to provide any form of network
> asserted identity that could be used in any useful way. Generally, the
> idea was that insertion of Call-Info was either done by the UA, or in
> the case of proxy-inserted values, was for "opt-in" services were the
> user had signed up for content to be added. That said, there are
> certainly cases where the caller may opt in for this service 
> but require
> privacy for a particular call, and we need a mechanism to 
> support that.
> 
> However, in no way would I support or advocate the use of Call-Info as
> an alternative for R-P-ID. 
> 
> > 
> > 2) Abuse of From/To headers
> > 
> > Jon is concerned that 'untrusted RPID' provides a standardised
> > alternative to From/To, allowing Bad Things, like never 
> putting the real
> > From/To information in the From/To fields.
> 
> I think that the proper way to handle this, as pursued in 
> other threads,
> is to provide a sane alternative to 3gpp so that they don't do this. I
> believe we all agreed it would be bad.
> 
> > 
> > Others have pointed out that the draft explicitly states 
> that untrusted
> > UAs MUST NOT add RPID. However the draft explicitly described proxy
> > handling of RPID headers from untrusted sources (proxies OR 
> UAs), and
> > allows these to be propogated, marked as untrusted.
> > 
> > Therefore, a UA which DID add RPID, although non-compliant 
> to the draft,
> > would have its RPID propogated through the network.
> > 
> > 3) 'Untrustworthy RPID'
> > 
> > Flemming, Bill et al argued that RPID information is still 
> useful when
> > it is 'untrustworthy'. This can occur legitimately within 
> the draft when
> > an RPID which is not 'private' (and so not encrypted) 
> crosses a trust
> > boundary. This would represent an identity asserted by Network A and
> > passed to Network B, when B has no explicit trust 
> relationship with A.
> > 
> > The contention was that since this information still has 
> some value, it
> > should be passed to the UAS for display, and might also have some
> > application for call trace, although obviously not as useful as a
> > 'trustworthy' identity.
> > 
> > Jon argued that the From field provides well enough for 
> display, and the
> > value of untrustworthy information for call trace is 
> debatable (and has
> > been debated at length).
> 
> IMHO, 'untrusted RPID' is identical to the From, except that it is
> purportedly inserted by a network element, whereas From is purportedly
> inserted by the end user. Neither provides any guarantees. The essence
> of the debate, I think, is whether you believe there is value 
> to the end
> user in a field which is the identity purportedly inserted by some
> network element.  Since there is apparently value to the identity
> purportedly inserted by the end user, I see no reason why we should
> discriminate. 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 11 Apr 2002 13:23:12 -0500

Mark wrote:
---------------

(*) IF the UA is allowed to put identity information into From/To, THEN
the Service Provider will be forced (by Data Protection) to provide
services which modify these fields, in order to protect the privacy of
people other than the actual calling user - subscriber, forwarding etc.

1) *Require* permanantly that the UA does not put identity information
into From/To 
----------------

Just to be a "devils advocate",  I suggest other alternatives:

4) Require that the UA anonymize the To and From headers IF requesting
CLIR on a call, and allow them to populate those headers as desired when
NOT requesting CLIR.

And the "modest suggestion" alternative:

5) Use a non-Internet protocol which completely constrains the service
functionality and user experience to a least common denominator and stop
pretending that your requirements have anything to do with the Internet.

Look, there are two reasons why we may want to use Internet protocols:

1) Because Internet protocols and approaches offer a substantially
richer, more flexible alternative which provides compelling advantages
in terms of service delivery options relative to traditional PSTN
approaches.

2) Because we're jealous of the success the Internet has had and want to
contaminate it with "telco like" requirements so that Internet people
can be miserable too.

I don't know about you, but I believe in #1, and would argue that if we
accept (*) as a requirement, that we're leading down the slippery slope
towards #2, leading to what will be a large push from certain segments
(witness Path discussion) to adopt alternative #5. Alternative #4 is a
reasonable compromise which keeps the responsibility were the Internet
says the responsibility should be, in the hands of the user.

Perhaps instead of To: and From: we should have called these headers
"What-I-will-Call-You:" and "What-I-Want-You-To-Call-Me:". These headers
have ABSOLUTELY NO SEMANTIC VALUE at the signaling and routing level.
They are HUMAN SUPPLIED values intended for HUMAN CONSUMPTION. There are
many other human-supplied values possible in the signaling, and the risk
of privacy violation is equally present on ALL of them.

If we earnestly believe that Data Protection is going to require that
we, by policy, alter these human-supplied/human-consumed values, then
we're logically going to have to do the same for every other
human-supplied/human-consumed values. I would argue that this completely
defeats the value of an Internet protocol in this context.

I believe it is significantly more effective to provide guidelines on
human-supplied/human consumed values, and implement hard requirements
for data protection only on network-supplied values.

--
Dean

_______________________________________________
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: Chris Martin <[email-masked]>
Date: Thu, 11 Apr 2002 14:16:48 -0500

I AGREE with 3!

:^)

> (*) IF the UA is allowed to put identity information into From/To,
> THEN the Service Provider will be forced (by Data Protection) to
> provide services which modify these fields, in order to protect the
> privacy of people other than the actual calling user - subscriber,
> forwarding etc.
> 
> 2) Reject requests where the UA puts identity information in From/To
> if privacy is required
> We all agree that (1) is bad. (2) looks attractive but is not
> backwards compatible, requires a double request (not good for
> wireless) & has issues as to whether you trust the UA (in redirection
> scenarios).
> 
> I was looking for a consensus that (3) is a possible and valid thing
> to do for these Service Providers. If the IETF SIP group agree that
> (3) and not (1) is _a_ valid solution to this problem, then there is
> more chance of other fora adopting (3) instead of (1).
> 
> So far, people have been arguing against the belief (*). The question
> is not whether (*) is demonstrably true but whether there is
> sufficient *chance* of it being true to justify serious consideration.
> A significant group of Service Providers obviously think it is - they
> are worried they will be in this situation and want a solution defined
> - that should be enough for us to discuss solutions.
> 
> So, can we agree to recommend at least that people with belief (*)
> adopt solution (3) and not solution (1) ?
> 
> ...Mark
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Apr 2002 22:01:10 -0400

inline.

Mark Watson wrote:
> compatible, requires a double request (not good for wireless) & has
> issues as to whether you trust the UA (in redirection scenarios).
> 
> I was looking for a consensus that (3) is a possible and valid thing to
> do for these Service Providers. If the IETF SIP group agree that (3) and
> not (1) is _a_ valid solution to this problem, then there is more chance
> of other fora adopting (3) instead of (1).

Honestly, I am flattered that you are hoping for the IETF blessing for
building a service. However, building such an anonyzmizer in (3) is well
within the scope of the SIP protocol, and requires no standardization
activity or consensus from IETF. I personally believe that you need a
full b2bua, since privacy, from a user perspecitve, WILL involve
stripping everything which might reveal identity, no matter whether the
header formally has identity information or not. Thus, I am not sure
what there is to do, but to emphasize to our friends in 3gpp to NOT
always put anonymous values in the To/From as this clearly will break
all reasonable interop with the outside world. (1) is BAD. Does anyone
dispute that?

-Jonathan R.