Subject: RE: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 12:33:26 -0600

A few notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 5:33 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
> Subject: Re: [Sip] Comment, SIP Privacy draft
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> 
[snip]
> 
> OK - so we agree that Call-Info duplicates Remote-Party-Id functionality
as far
> as this point is concerned. All we need is someone specifying the usage.
> 

I really hope we all agree that the "proposal" Bill made to conflate RPID
and Call-Info was not serious, but was intended to make a point about
underspecification in the SIP spec, and also to illustrate that Call-Info
has its own privacy implications. Right?

I think it would be problematic to suggest that the Call-Info and RPID
should be conflated, as the remainder of my note bears out.

[snip]
> 
> >
> > Should there be a mechanism in SIP that allows a user agent 
> to suggest that
> > proxies treat their requests privately? Of course. I think 
> the presence of
> > some sort of privacy flag/header in requests is a 
> reasonable way to do so
> > (vide the RPID-Privacy header in sip-privacy today). 
> Guaranteeing privacy
> > entails managing a number of headers that could potentially 
> divulge identity
> > - Call-Info is one of many examples (the open-ended 
> User-Agent and Server
> > headers could also be used as repositories for potentially 
> private data, let
> > alone common headers like Via and Contact).
> 
> Indeed they could, just like a Remote-Party-Id header can be used in ways
people
> did not intend to. But why is it, that this must be obstructed at all cost
in
> the privacy-draft case, but it's perfectly legit in the SIP spec ? In
fact, if I
> rewrote the privacy-draft to use Call-Info instead of Remote-Party-Id,
what
> would your arguments now be ?
> 

To limit the scope of the Call-Info, since the Call-Info is not intended to
be an network-verified identity carriage parameter. Of course.

This is not 'legit' in the SIP spec. We all know that in the two-hundred-odd
pages of the SIP spec there are many remaining nits and gotchas, even when
one is not reading the text in bad faith. This is clearly a bad faith
reading of 20.9. No one would honestly believe that Call-Info is intended as
a network-verified identitiy carriage mechanism. If that were proposed, I
believe the authors of bis09 would say that was not a correct usage.

The real, material difference here is that people want to do Bad Things with
RPID, and RPID has broadened its definition and its mechanism to accomodate
these things in the name of privacy. Call-Info is merely underspecified.

> >
> > All that said, I feel that it is somewhat misleading to suggest that
> > Call-Info and RPID actually have a similar function, or more directly,
that
> > Call-Info should in fact be replaced with RPID.
> 
> Well, I would actually argue the other way. Let's drop Remote-Party-Id and
just
> use Call-Info since nobody can object to that.
> 

I can object, and I would. Why would anyone fail to object to that usage?

> > The note below actually
> > suggests Call-Info could be used to implement a CLIP/CLIR service -
suffice
> > it to say I do not believe this was the intention behind 20.9 in bis09.
> 
> Ahh, but it could be used in that way - why is there not an applicability
> statement to make sure it can't be misused ?
> 

Although I already said this above, it is worth reiterating that RPID
purports to be a privacy mechanism, but it has been earmarked for use in a
number of ways that reflect poorly on privacy.

[snip differences between RPID and Call-Info]
> 
> Well, why on earth are proxies allow to muck with it then ? Also, why does
it
> talk about "trust that element" ? This all sounds very familiar to me.
> 

To your first question, I dunno, actually. I mean, I guess I could see cases
where a service provider wanted to add their homepage HTTP URI to a request
as it passed as a kind free advertising. Really, those are the only sorts of
cases I can imagine.

To you second question, if you get an email from someone that you don't know
which contains an HTTP URL, should you follow that URL? No, it could lead
you somewhere you don't want to go, or worse, download some malicious
software. This is all that "trust that element" note is saying. People have
really chosen to read that in a hostile way.

[snip]
> >
> 
> Hmm, I quote:
> 
>     "Therefore, it is RECOMMENDED that a UA only render the information in
the
> Call-Info header field if it can verify the authenticity of the element
that
> originated the header field and trusts that element."
> 

And your quotation here supports what position, exactly? The account I gave
above of why you shouldn't follow arbitrary URLs was the motivation for this
text, as far as I remember, and I read this as consistent with the above.

> 
> 
> > Any resemblance between the two headers further breaks down when we
begin to
> > look at the functional behavior of RPID - when it is added, how
screening
> > operates, and so forth. The most important difference is that Call-Info
> > entails no concept of trusted and untrusted networks which are most
> > certainly entailed by the RPID header. The use of the RPID header is
> > predicated on the configuration of a set of 'trusted' destinations which
can
> > inspect the RPID header, and the assumption that it must be removed if
it is
> > transferred to an untrusted entity. Personally, I don't think Call-Info
> > requires any such concept if it is used as the spec seems to intend.
> >
> 
> A couple of problems here. First of all the Call-Info talks about trust
without
> specifying what that is. Secondly, you are talking about providing privacy
for a
> Call-Info header which you agreed above would be valuable, so the part
about
> "removing" before forwarding to untrusted entities ends up being the same
(you
> agreed above that a generic privacy mechanism should cover Call-Info).
Finally,
> Remote-Party-Id is not supposed to be removed when forwarded to an
untrusted
> entity - it is supposed to be encrypted so we can do call trace.
> 

It's clear to me, anyway, that the 'trust' here is unrelated to the 'trusted
network' concept in RPID. For one thing, the trust of Call-Info is a matter
of human oversight. In much the same way that you choose to follow a URL in
an email or not, you can choose to follow the URL in a Call-Info - this URL
is intended to be consumed by humans. This is radically different than the
identity in an RPID. Automatons (proxies) need to decide programmatically
whether or not they "trust" the next hop to which they are sending
signaling, and groom the RPIDs in messages appropriately. These two forms of
trust are quite different.

I see Call-Info as one of many ways that potentially private information
could be communicated inadvertantly to an end user, so in that sense I agree
it is valuable for the general SIP privacy mechanism to discuss Call-Info.
However, I don't think Call-Info should play a role in expressing a
network-verified identity of end-users.

sip-privacy-04 says 'encrypt or remove', yes. But not enough information
about encyrption is provided for that to be a viable option - this isn't
entirely the privacy draft's fault, but sip-privacy-04 could have said more
than it does, anyway. It is also not clear to me how 'encryption' helps call
trace. Encryption would only be relevant to call trace in so far as all
entities that will be able to decrypt the RPIDs are trusted, and that
trusted elements encrypt the RPIDs so that they can pass through untrusted
entities on the way to some other trusted entity. Encryption doesn't really
make decisions about trust any easier (which key do I to encrypt RPIDs when
I send them to an untrusted source? how do I know where the signaling will
eventually end up?), it just pushes the problem around.

> 
> >
> > The argument that Call-Info is a subset of RPID I also find a little
> > troublesome - when properly configured quite a few SIP headers,
including at
> > least To and From, could be represented by RPID. With the current
> > extensibility mechanism in sip-privacy-04 I have no doubt it could be
argued
> > that RPID should replace all other means of asserting identity in SIP.
> > Personally, I believe this is a defect of sip-privacy-04 rather than a
> > strength.
> 
> Yeah, nothing like the good old smokescreen. Nobody has suggested the
above so
> let's leave this out - shall we ?

I am trying to argue in good faith here - this is not meant to be deceptive,
but rather just to illustrate that if you want to conflate RPID with
Call-Info, there are quite a few other headers you could also choose to lump
in with those two. It is dangerous to go down that path, I think.

> -- Flemming
> --
> Flemming Andreasen
> Cisco Systems

_______________________________________________
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: Flemming Andreasen <[email-masked]>
Date: Fri, 29 Mar 2002 14:03:02 -0500

Lots of snipping...

> has its own privacy implications. Right?

No, we are actually quite serious. We have a problem that needs a solution, and
if the privacy draft ends up dying or otherwise does not provide that solution
very soon, we need an alternative. Since Call-Info is already spec'ed and we are
low on alternatives, the choice is pretty clear.

> should be conflated, as the remainder of my note bears out.

We can all agree it is not ideal, but we are given little choice.

> believe the authors of bis09 would say that was not a correct usage.

As far as bad-faith reading of specs is concerned, this is hardly the only
example as I pointed out in previous e-mails.

> I can object, and I would. Why would anyone fail to object to that usage?

You cannot object to using an already defined header in specific ways,
regardless of whether it was intended to be used that way or not.

> software.

I wish you would explain that to my HTML enabled e-mail reader, 'cause it sure
doesn't work that way.

> network-verified identity of end-users.

Neither do I, but I need an agreeable alternative, and I don't see that
anywhere.

> entities on the way to some other trusted entity.

I think you have misunderstood how this aspect works. The encrypting entity is
the one that will perform the decryption - the hostport identifies the
encrypting proxy and hence normal SIP routing of requests with such a
Request-URI solves your problem.

> Encryption doesn't really

Not really since you know that if there is a need to decrypt it (the call trace
case), you will in fact get in back to where it was encrypted and hence there's
no need to specify anything. If on the other hand you are talking about the
general case of passing Remote-Party-Id around inside your trusted boundary,
then I agree - the draft actually states that there are many unsolved issues
here (which is the Proxy-Require option is in there).

-- Flemming