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

[Mary Barnes <[e-mail]>]

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 <[e-mail]> 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
>
> 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:[e-mail].  But in
>> that
>>  context, it's true the aliceproxy.com H-I has to be anonymized, but
>>  clearly not sip:[e-mail] 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>