Jonathan, Thank you for the comments for the privacy-new draft. See inline.
> 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. Will add this in the section 1. > > >> 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. "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". > >> 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. 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. > >> Proxy Behavior > > The draft should talk about RFC 3325 in particular. Okay. > > 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. Right, I think we simply copied the terminology from the RFC3323, will modify the text to be more concise. > >> The protection of network >> privacy (e.g., topology hiding) is outside the scope of this >> document. > > You need to clarify what this means. Will do. > >> 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? I guess we will rewrite it to say, URI SHOULD support and if support MUST utilize the GRUU mechanism. > >> response for a "temp-gruu" URI parameter, which provides the desired >> privacy property. > provides URI with the desired property Will fix. > >> 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. Will fix. Thanks, Mayumi > > > > Thanks, > Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
