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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 May 2002 12:50:20 -0500

Thanks for the comments, Ben. We need 'em.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2002 3:10 PM
> To: Peterson, Jon; sip
> Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> 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.

How about we move it to the Sec Cons - as far as I can make it, the Sec Cons
is a ghetto for well-meaning non-normative statements along these lines. 

> 
> "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.)

I can s/glean/guess.

> 
> "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" :-)  )

Fortunately, RFC2606 beat us to it. Perhaps I should list this as a
reference.

> 
> "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?

I can see why this language would make you a little nervous. I think there
are perhaps a couple of good reasons to allow communities of privacy
services that can forward requests among one another (wiser authors in the
future might design onion routing schemes for SIP requests, or something).
Agreed there are some transitivity issues here - it is absolutely critical
that the user is related to the service that performs the privacy function.
Then again, if their privacy server has already performed some privacy
functions before forwarding the request (say, 'header' privacy), then a
second privacy service that performs additional functions ('session', say)
might not be in a position to even identity the originating user. There are
cases where this is useful, I think. I'm sensitive to your concerns, and I
think they merit some language, but I'm not sure what to add.

> 
> "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."
> 

Are there any conditions in which the fulfillment of a request is predicated
on the population of any of those three headers? Maybe this is also related
to criticality - if a server must populate those headers, but cannot because
of a critical privacy condition, then it should most likely fail the
request.

> "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.
> 

Well, it's true that we shouldn't be trying to dispense legal advice as
such, but I feel the basic principle that is outlined here is worth
mentioning if we can eliminate any implication of professional counsel. I'll
see if I can't manage that.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 16:13:52 -0400

"Peterson, Jon" wrote:

> Fortunately, RFC2606 beat us to it. Perhaps I should list this as a

Yes. In fact, its normative in order to ensure exactly the property ben
was worried about.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com