Subject: Re: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:00:37 -0700

This suggestion is certainly not in the wacky category so my  
apologies for the subject line :-)

What you are suggesting here may have possibly been a much better  
design than what we have. There would be several advantages (like  
being able to specify more about the level of protection).

The issues with it were that we were passing URI around between  
things. Take a REFER for example - now I suppose that you could embed  
the requires into the URI but in practice theses don't get processed.  
A contact getting copied out of one dialog and into some new dialog.  
A subscribe that sets up a notify. There are many examples. There was  
also the questions of what level of granularity we needed to be able  
to describe the level of protection. I think the feeling at the time  
was that one very rough cut (reduced to a single bit) could work for  
many things given the transitive trust assumptions that were  
intrinsic in any security based on hop by hop.

The questions we are at now is, given the choices we made, would it  
be possible to even change this. The backwards compatibility issues  
are not so much the places were we did something specific for a URL  
but all the places that we allowed URL to be copied we would need to  
think about how the protection parameters associated with them got  
copied.

I'm not saying that this path is not worth thinking about it -  
perhaps we can figure something out along these lines.

On May 30, 2006, at 4:04 AM, Christer Holmberg ((JO/LMF)) wrote:

>
> So, what you are saying:
>
> sips:[email-masked]
>
> =
>
> sip:[email-masked]
> Require: integrity-and-confidentiality-protection
> Proxy-Require: integrity-and-confidentiality-protection
>
> ?
>
> If so, and if people have problems with sips, and what it really  
> means,
> why not then simply define an option tag to be used in a
> Require/Proxy-Require header?
>
> Regards,
>
> Christer
>
>
>
> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 30. toukokuuta 2006 8:03
> To: Sip
> Subject: Wacky thead of the month award goes to ... Re:
> [Sip]draft-audet-sip-sips-guidelines: Meaning of sips
>
> I plan to very seldom sends emails with my AD hat on but I think I  
> will
> make an exception for this one. This may be a learning experience  
> for me
> in trying to provide some of that "Steering" part of the IESG role.
>
> sips is not analogous to https or the lock icon on a browser. When
> firefox puts up the lock icon, some of the things it tries to mean is
> that you are connected to the website you think you are connected and
> your data in encrypted.
>
> sips was never meant to imply that you were talking to the person in
> your To header field value or that your RTP is somehow encrypted. It
> does not solve either of those problems. We have several working  
> groups
> in the RAI  and Security area that are working to provide solutions to
> these two security issues and others. That sips does not provide these
> does not in any way mean that sips should be deprecated. In many
> situations, sips provides a very powerful security primitive that
> protects against several things. Many of these were brought up on this
> thread.
>
> I would like to point at one in particular. Imagine the hypothetical
> case where Brian has a phone at Neustar and trusts Neustar, and I  
> have a
> phone at Cisco  and trust Cisco. Using sips for a call that goes from
> Brains phone to the Neustar proxy to the Cisco proxy and to my phone
> provides a surprisingly strong system for many attacks. Note that
> Brian's proxy found no need to route the call through an AT&T proxy in
> the middle. Now Brian and I might not want to use this signaling  
> channel
> for things that we did not want Cisco or Neustar to know about but  
> this
> channel could help secure many things that were reasonable business
> items between Cisco and Neustar. In this case, sips can help be a tool
> that can be used to achieve the desired security. For communications
> where I would not trust Cisco or Nuestar, we will might use AOR at
> domains we trust for that purpose - like our own domains.
>
> I think that at the high level, the semantics of sips are simple. We
> want it to mean that every hop from the UAC to the UAS was  
> integrity and
> confidentiality protected at a reasonable level assuming transitive
> trust. This can be very useful. At the more fine details level, we  
> have
> some parts that are unclear in how to implement it, we probably have
> some bugs in the spec, and perhaps we even one place where we made  
> a bad
> choice that we may correct. I'm very keen on this draft - I want it to
> try and sort out the details that are missing or wrong.
>
> sips is not the answer to every problem. Note even 3261 had S/MIME and
> we have done Identity, SRTP, and many more. However SIPS is a useful
> tool for creating security solutions and we should sort out any  
> missing
> details.
>
> Cullen <with my AD hat on>
>
> Now bring on the rotten vegetables.
>
>
> _______________________________________________
> 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

_______________________________________________
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