Subject: Re: [Sipping] Discussions on draft-munakata-sipping-privacy-clarified-00

From: Mayumi Munakata <[email-masked]>
Date: Thu, 02 Nov 2006 17:51:32 +0900

Jonathan,

Thank you for the valuable comments.

To my knowledge, RFC 3323 is widely deployed already, so it is necessary to keep the mechanism and clarify it as much as possible for the already deployed implementations.

Your sip-identity-privacy draft may solve all the privacy problems, but still, we need RFC 3323, even if it is a short-term solution.

If everybody views RFC 3323 in the same way, I can change the text in Section 4.2. (Guidelines on specifying new priv-values) to something like "it is RECOMMENDED to avoid defining a new priv-value in future RFCs".

Thanks,
Mayumi

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 17:54:44 -0500

Let me follow up some more to my remarks at the microphone today.

We clearly have a need for privacy services in SIP, and a revision of 
RFC 3323 is warranted.

What I think such a revision should do is:

1. give guidance on how a UA can construct a completely anonymous 
request, utilizing anonymous gruu and using TURN to obtain IP addresses 
and ports for media relay. This would need to have guidance on various 
header fields, as rfc 3323 does today. However the context there is how 
to construct (or omit) them, rather for guidance on removal or manipulation.

2. Once you define (1), the additional service you need from the network 
is not to insert aFrom [email-masked] Mon Nov 06 21:46:48 2006
Date: Mon, 06 Nov 2006 17:54:44 -0500
From: Jonathan Rosenberg <[email-masked]>
To: Mayumi Munakata <[email-masked]>
Subject: Re: [Sipping] Discussions on
	draft-munakata-sipping-privacy-clarified-00
Cc: [email-masked]

Let me follow up some more to my remarks at the microphone today.

We clearly have a need for privacy services in SIP, and a revision of 
RFC 3323 is warranted.

What I think such a revision should do is:

1. give guidance on how a UA can construct a completely anonymous 
request, utilizing anonymous gruu and using TURN to obtain IP addresses 
and ports for media relay. This would need to have guidance on various 
header fields, as rfc 3323 does today. However the context there is how 
to construct (or omit) them, rather for guidance on removal or manipulation.

2. Once you define (1), the additional service you need from the network 
is not to insert additional information into the request which identify 
the user. Thus, you need a flag that indicates the request is anonymous. 
We could use the Privacy: id value for this, or use the presence of an 
anonymous URI in the From as this flag. What I assert we do NOT want is 
anything more than just a single flag. We don't want specific guidance 
on whether its allowed to insert header foo vs. header bar. That is too 
complicated and I think is not useful.

3. Additionally, one might want a solution for UA which, for some 
reason, cannot construct messages using (1). In that case, the UA will 
want to invoke a privacy service in the network. I would argue that we 
DONT want complex features that allow the UA to micro-manage the 
behavior of that privacy service. As a privacy service, it does a 
"full-processing" on the request - removing or obfuscating anything that 
could reveal user identity. Thus, the only thing we need to signal is a 
way for a UA to invoke that service, thats it. We could use a Privacy 
value for that, or we could use other techniques we have developed for 
service invocation. For example a route header field that points to an 
anonymization service.

I will point out that RFC 3323 itself has only seen deployment in the 
context of RFC 3325. That is, to my knowledge, the only value of the 
Privacy header ever used is "id".

-Jonathan R.

Mayumi Munakata wrote:

> To my knowledge, RFC 3323 is widely deployed already, so it is
> necessary to keep the mechanism and clarify it as much as possible
> for the already deployed implementations.
> 
> Your sip-identity-privacy draft may solve all the privacy problems,
> but still, we need RFC 3323, even if it is a short-term solution.
> 
> If everybody views RFC 3323 in the same way, I can change the text in
> Section 4.2. (Guidelines on specifying new priv-values) to something
> like "it is RECOMMENDED to avoid defining a new priv-value in future
> RFCs".
> 
> Thanks, Mayumi
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Mayumi Munakata <[email-masked]>
Date: Tue, 07 Nov 2006 16:26:24 +0900

Hi Jonathan,
Thank you for the follow up.

We are using "id" and "none", and it seems like there are 
some implementations that already deploy "header", too. 
Other priv-values ("user", "session", and "critical") 
could be deprecated if they are really not used in anywhere.

However, your proposal to use Privacy: id as a flag to 
indicate a server not to add any identity information will
ruin the backward compatibility.  We would prefer to define 
a new priv-value like "all" as this flag.

What about "history" privacy?
As Roland mentioned in the other email "The 'history' privacy can 
be within the Message or within the History Info header itself", 
privacy=history can be set in a History-Info header in order to 
request the privacy for each hi-entry.
I guess this mechanism should not be deprecated because there 
are use cases and can not be realized without this.

Thank you,
Mayumi

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 6 Nov 2006 12:50:20 -0500

"user" is used as well (as is "header" and "none", and obviously "id").
-hadriel

> -----Original Message-----
> From: Mayumi Munakata [mailto:[email-masked]]
> Sent: Tuesday, November 07, 2006 2:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Discussions ondraft-munakata-sipping-privacy-
> clarified-00
> 
> Hi Jonathan,