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

Paul Kyzivat <pkyzivat@cisco.com> Mon, 30 August 2010 21:01 UTC

Message-ID: <4C7C1C1F.8040100@cisco.com>
Date: Mon, 30 Aug 2010 17:01:19 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: sipcore issue tracker <trac@tools.ietf.org>
References: <064.c332b45494f9c1c0917449f41a07017b@tools.ietf.org>
In-Reply-To: <064.c332b45494f9c1c0917449f41a07017b@tools.ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: sipcore@ietf.org
Subject: Re: [sipcore] #16: Privacy behavior is confusing
Precedence: list

[ 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

sipcore issue tracker wrote:
> #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:Bob@aliceproxy.com.  But in that
>  context, it's true the aliceproxy.com H-I has to be anonymized, but
>  clearly not sip:Bob@bobsproxy.com 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.
>

[sipcore] #16: Privacy behavior is confusing sipcore issue tracker
Re: [sipcore] #16: Privacy behavior is confusing Paul Kyzivat
Re: [sipcore] #16: Privacy behavior is confusing Mary Barnes