Subject: [Sip] comments on draft-munakata-sip-privacy-new

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 08:10:24 -0400

Overall this draft is excellent and exactly what I think it should be 
for this. Some comments below, major and nits:

Major:

Section 1: There are some additional problems worth noting:
   * privacy service has to be a b2bua and thus interferes with security 
mechanisms that break in the face of b2bua, such as sip identity (which 
provides message integrity and works well here too to provide the remote 
side an assurance of authenticated identity, just one that is not 
provided), which in turn breaks dtls-srtp

* because of the need to signal from the UA to the privacy service 
exactly the desired functionality, the set of functionalities possible, 
in terms of what is anonyzmized and what is not, is bounded and required 
detailed specification.

> The user agent setting the "temp-gruu" as a GRUU SHOULD set
>    "Anonymous" as a display name in any header where the display name of
>    the originator is set.  That indicates the anonymity of the request
>    to intermediaries that may invoke some services based on the
>    anonymity of the call.

Hmm, I'd prefer something explicit. There are problems with using 
human-readable and locale-specific text like display name to signal to 
automata.

> Note: A relayed IP address may be used for a Via header, but some
>          commented that is not an appropriate to be used for signaling.
>          There was a comment about the IP address in Via being stripped
>          by the proxy, but that would require that a proxy compliant to
>          this specification is in the signaling path.

I think it was me you said you didn't need this. You make a good point 
here however.

> Note: The mechanism of the flag is FFS.

 From text above I thought it was presence of the Anonymous in display 
name, which is bad. I personally like the Privacy: id value since its 
effectively what everyone is using and also backwards compatible.

I also think we need something to make sure the terminating UA doesn't 
try to render the From or P-A-ID if someone should insert.

>  Proxy Behavior

The draft should talk about RFC 3325 in particular.

Nits:

> privacy service.  This document proposes a new privacy mechanism that
>    a user agent can facilitate to conceal privacy-sensitive information
>    without the need for aid from a privacy service.

This is somehwat misleading; there is a privacy service in the form of 
turn servers and proxies.

> The protection of network
>    privacy (e.g., topology hiding) is outside the scope of this
>    document.

You need to clarify what this means.

> A user agent wanting to obtain functional anonymous URI SHOULD
>    support and SHOULD utilize the Global Routable User Agent URI (GRUU)
>    mechanism. 

Isn't this going to need to be a MUST?

> response for a "temp-gruu" URI parameter, which provides the desired
>    privacy property.
provides URI with the desired property

> It is assumed that a user agent is either manually or automatically
>    configured through means such as a configuration framework with one
>    or more STUN relay servers.

terminology has changed again; these are now called TURN servers once more.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Mayumi Munakata <[email-masked]>
Date: Wed, 25 Jul 2007 09:21:22 +0900

Jonathan,

Thank you for the comments for the privacy-new draft.
See inline.

> * privacy service has to be a b2bua and thus interferes with security mechanisms that break in the face of b2bua, such as sip identity (which provides message integrity and works well here too to provide the remote side an assurance of authenticated identity, just one that is not provided), which in turn breaks dtls-srtp
>
> * because of the need to signal from the UA to the privacy service exactly the desired functionality, the set of functionalities possible, in terms of what is anonyzmized and what is not, is bounded and required detailed specification.

Will add this in the section 1.

> Hmm, I'd prefer something explicit. There are problems with using human-readable and locale-specific text like display name to signal to automata.

"Anonymous" display name is not used for explicit indication of anonymity to the
intermediaries, rather this is specified to be aligned with the ACR draft. AFAIK
the ACR draft explicitly states the spelling of display-name to be either "Anonymous"
or "anonymous".

> From text above I thought it was presence of the Anonymous in display name, which is bad. I personally like the Privacy: id value since its effectively what everyone is using and also backwards compatible.

This is based on few assumption.
1. privacy value beside "id" is not used.
>> This sounds almost true, but I have heard several vendors and providers actually utilizing these values to
micro manage the privacy treatment of messages, in which case overloading the semantics of "id" may
be problematic when older privacy service is treating the message as noted on the slide today.

2. information beside what's inserted by the UA is not a privacy concern.
>> Information readily added by the intermediaries such as Record-Route, Via etc. are not privacy
sensitive. You have to be making this assumption to overload the "id", as it is possible that older
privacy service would only remove the P-A-ID and forward the listed values above which are
considered to be a target of privacy in RFC 3323.

Anyhow, without thorough knowledge of what's really deployed in the wild, it is rather dangerous to
make any assumption and overload the "id" value.

>
> I also think we need something to make sure the terminating UA doesn't try to render the From or P-A-ID if someone should insert.

Good point.

AFAIK, the Privacy header is removed when the last value for the privacy header is removed so something is needed. Having that said, you seemed to be implying that something needs to be there to convey that UAC is requesting the privacy, yet survives translation and treatment of privacy service and other intermediaries.

> The draft should talk about RFC 3325 in particular.

Okay.

> This is somehwat misleading; there is a privacy service in the form of turn servers and proxies.

Right, I think we simply copied the terminology from the RFC3323, will modify the text to
be more concise.

> You need to clarify what this means.

Will do.

> Isn't this going to need to be a MUST?

I guess we will rewrite it to say, URI SHOULD support and if support
MUST utilize the GRUU mechanism.

> provides URI with the desired property

Will fix.

> terminology has changed again; these are now called TURN servers once more.

Will fix.

Thanks,
Mayumi