Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general

From: Ben Campbell <[email-masked]>
Date: Wed, 29 May 2002 17:10:25 -0500

Some comments. My mail reader didn't want to cooperate on quotes--the 
text between "" is from the draft.

Most of these are really nits

"Note that there is a fine line between identity fraud and humor in some 
cases. Many email clients by default render to the user only the 
display-name of the sender of a message. It is easy to populate the 
display-name in a way that many would consider abusive; it is best not 
to select any display-name that may suggest an attempt to impersonate 
someone else."

This section sounds like something that belongs in a bcp, not in a draft 
that I assume is intended to become a normative RFC.

"From the former [sip:[email-masked]], the full name and 
employer of the party in question can easily be gleaned. From the 
latter, you learn nothing other than that the party desires anonymity. 
In some cases, sufficient anonymity can be achieved by selecting an 
oblique URI. Today, the SIP specification recommends a URI with 
"anonymous" in the user portion of the From header."

Hmm, I fear someone might read this and believe too much, that is, that 
they could really know the identity of the sender from a URL in a From 
header. For example, _I_ could use that URL. If you glean something from 
it, you would glean wrong. (Perhaps s/glean/guess would be sufficient here.)

"For these reasons, the hostname value 'anonymous.invalid' SHOULD be 
used for anonymous URIs. The full recommended form of the From header 
for anonymity is (note that this From header, like all others, MUST 
contain a valid and unique 'tag=' parameter): "

Does this require reserving anonymous.invalid to never resolve to 
something real? How would you enforce that? (Maybe a new TLD for 
"invalid" :-)  )

"If the 'critical' privacy level is present in the Privacy header of a 
request, then if the privacy service is incapable of performing all of 
the levels of privacy specified in the Privacy header then it MUST 
either fail the request, or it MUST forward the request to another 
privacy service which can fulfill these functions (note that before 
forwarding the request, the privacy service SHOULD complete a subset of 
the functions if it can). "

This one scares me a little. It implies that, even if I have gone to a 
great deal of trouble to directly talk to a privacy service (perhaps 
over TLS) and specify "critical", it can still forward the request 
without having performed privacy services. Doesn't this brings up the 
whole transitity of trust and trust boundery issue that we keep getting 
bogged down on?

"Firstly, a request for header privacy entails that the server SHOULD 
NOT add any of the following headers to the message: Call-Info, Server, 
and Organization. All of these provide optional information that could 
reveal facts about the user that has request anonymity. "

I would be happier if the situations that would allow the server to 
insert one of those headers were enumerated. More of a "MUST NOT unless" 
form. I tend to think it should be "MUST NOT unless it is impossible to 
fulfill the SIP request without doing so."

"Privacy services would be wise to authenticate users before providing a 
privacy function. To downstream entities, the privacy service will be 
the only responsible party to whom anonymous messages can be traced, and 
in abuse cases the privacy service could be held accountable for the 
actions of parties that it shelters. "

I'm not sure I agree with this. In some cases, _not_ authenticating 
might be the only defence against sopoena(sp?). This paragraph falls 
into the area of legal advice that should be given by lawers.

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Thu, 30 May 2002 13:26:25 +0100

"When a privacy service performs one of the functions corresponding to
   a privacy level listed in the Privacy header, it SHOULD remove the
   corresponding priv-value from the Privacy header - otherwise, any
   other privacy service involved with routing this message might
   unnecessarily apply the same function, which in many cases would be
   undesirable."

This seems to be in contradiction with draft-ietf-sip-asserted-identity,
which show "Privacy: id" being maintained with the forwarded INVITE.

   "When the last priv-value (not counting 'critical') has
   been removed from the Privacy header, the entire Privacy header MUST
   be removed from a message."

Is this wise in the case of "None"?

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 28 May 2002 22:32
> To: 'sip'
> Cc: [email-masked]; [email-masked]; [email-masked]; Jon
> Peterson ([email-masked])
> Subject: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> 
> We need to do a quick review of the general privacy draft 
> developed out
> of our discussion in Las Vegas.
> 
> Please send any issues to the list and the editor IMMEDIATELY.
> 
> The draft is available from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
> eneral-00.
> html
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
eneral-00.
txt
And soon to be available from internet-drafts if not already . . .

--
Dean