Subject: RE: [Sipping] Screened From: and Privacy

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 17 Apr 2002 14:34:59 -0400

I  keep wishing we could slice and dice this down to some things we
agree on and a short list of things we don't, but it doesn't seem to be
happening.

I'll try again.

Can we assume that Mark is correct about SUBSCRIBER (he who pays) as
opposed to USER rights?   I don't like it, but I conclude we
are stuck with it.

Can we assume a Network Asserted Identity is a requirement?  I actually
don't agree with all of Mark's proposed requirements yet, but I think
we HAVE to have it.

Can we possibly agree that an anonymizing B2BUA, provided by a service
provider, would be the only way to achieve real privacy?  I don't think any
of the short cuts like messing with this header or that header will do.

The only practical problems I am aware of with an anonymizing
B2BUA are crypto and DOS. In general, you can't use any kind of crypto
unless 
the B2BUA has the right secrets.  I vaguely remember some research on
anonymous crypto, but in general, it isn't interesting to be secure and 
anonymous completely. You could arrange security against outside 
snooping as long as the service	provider was part of the trust domain 
(which means the B2BUA could be trusted) and still be anonymous. 

If we had a reasonable network asserted identity, I think that is
sufficient to avoid the kinds of problems Christian pointed out
with anonymizers.  It's not truly anonymous - the SP knows who
called.

Brian

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 12:38 PM
To: 'Alan Johnston'; 'David R. Oran'; 'Dean Willis'; 'Sipping (E-mail)'
Subject: RE: [Sipping] Screened From: and Privacy

So, there is clearly disagreement on whether screened From: is a BAD THING
or a GOOD THING. 
I really feel that trying to argue that one side is RIGHT and the other
WRONG will not get us anywhere, and we should just work with the situation
as it is. I've just been trying to point out why some people have taken the
screening route.
Two things are independent of this, though: 
1) The need for Network Asserted Identity 
2) The need for anonymity services 
For the example service Juha gave, (1) is the only thing which would allow
him to turn off his From screening, so it is a little churlish to argue that
From screening is WRONG when there is presently no alternative.
Regards, 
Mark 
> -----Original Message----- 
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 17 April 2002 17:14 
> To: Watson, Mark [MDN05:EP10:EXCH]; 'David R. Oran'; 'Dean Willis'; 
> 'Sipping (E-mail)' 
> Subject: RE: [Sipping] Screened From: and Privacy 
> 
> 
> 
> Mark wrote: 
> 
> >I was trying to explain why the text in the SIP 
> specification may have 
> led Service 
> >Providers to believe that they ought to verify the From: 
> field. You are 
> arguing this is 
> >a wrong interpretation, but independent of that, I don't think people 
> who have 
> >interpreted the text that way are being unreasonable. 
> 
> I must have missed the 4xx From Header Incorrect response code which 
> must be somewhere in bis for this verification of From 
> identity to work 
> :-) 
> 
> I think this interpretation is totally unreasonable and should be 
> dispelled right now for what it is - a mistake. 
> 
> Service providers must read Internet specifications very 
> carefully - the 
> Internet and its protocols were not designed for them (fortunately). 
> 
> Thanks, 
> Alan Johnston 
> WorldCom 
> sip:[email-masked] 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 Apr 2002 13:46:26 -0500

> opposed to USER rights?   I don't like it, but I conclude we

yes

> don't agree with all of Mark's proposed requirements yet, but I think

yes

> of the short cuts like messing with this header or that header will
do.

yes

> (which means the B2BUA could be trusted) and still be anonymous.

one might argue that user-specific keys are themselves privacy
violations. One needs session re-keying at the B2BUA.

> with anonymizers.  It's not truly anonymous - the SP knows who

yes

Of course, there are OTHER requirements, but I think we're moving well
now . . .

--
Dean