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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 30 May 2006 13:04:13 +0200

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