Subject: [sipcore] #16: Privacy behavior is confusing

From: "sipcore issue tracker" <[email-masked]>
Date: Mon, 30 Aug 2010 20:15:07 -0000

#16: Privacy behavior is confusing
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  enhancement             |      Status:  new       
 Priority:  minor                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------
 [I'm submitting this ticket because when I read the draft the first few
 times, it kept annoying me.  But it could easily just be me and no one
 else.]

 Maybe it's just me, but I've read the draft multiple times and I find the
 Privacy header stuff for anonymizing H-I headers to be really confusing.
 In RFC 3323, the idea was for providing privacy of the *originator*
 information.  New headers could stipulate they also reveal such
 information and thus should be anonymized, but it's really debatable if
 H-I entries reveal information about the *originator*, vs. the target.

 The only way I can see they reveal originator info is because they can
 reveal the IP Address of the originator's proxy, or originator's domain,
 because Alice may send the request to sip:[email-masked].  But in that
 context, it's true the aliceproxy.com H-I has to be anonymized, but
 clearly not sip:[email-masked] once aliceproxy retargets to that.
 Furthermore, by forcing all H-I entries to be anonymized, it breaks the
 use of H-I for some pretty important uses.  You could say "well that's
 what anonymization means", but that's not true - it is NOT the case that a
 caller-id anonymized call does not get the right voicemail or ACD service.
 Because "anonymized" calls are about originator information, not
 destination information.  After all, the destination *knows* who you're
 calling... it's not a secret to Bob that you called Bob!

 What the draft needs to do is explain there are multiple "types" of
 Privacy: privacy to anonymize the originator, privacy to anonymize
 diverting targets from subsequent targets and the originator, and privacy
 to anonymize the final reached target from the originator.  The last two
 happen to work the same way: through the Privacy header being embedded in
 the H-I entries of responses.  The draft then needs to explain *why* the
 first case of originator information could be revealed by H-I, and why
 there needs to be support for anonymizing all the H-I's using the Privacy
 header for that first case.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/16>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 17:01:19 -0400

[ as individual ]

This, in combination with the comments I made on privacy, lead me to 
think that the whole privacy aspect may need to be rethought.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 30 Aug 2010 17:09:16 -0500

Yeah - we should probably revisit the privacy section, including your
concern on the domain terminology.  We can use this issue to track the
general problem.

On Mon, Aug 30, 2010 at 4:01 PM, Paul Kyzivat <[email-masked]> wrote:
> [ as individual ]
>
> This, in combination with the comments I made on privacy, lead me to think
> that the whole privacy aspect may need to be rethought.
>
>        Thanks,
>        Paul
>
>>  Reporter:  hkaplan@…               |       Owner:                 Type:
>>  enhancement             |      Status:  new        Priority:  minor
>>           |   Milestone:  milestone1
>> Component:  rfc4244bis              |     Version:  2.0        Severity:
>>  In WG Last Call         |    Keywords:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>