Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

From: "Francois Audet" <[email-masked]>
Date: Thu, 18 May 2006 20:42:12 -0500

> Based on what I am hearing, it seem like the best course might be to 
> deprecate SIPS and begin work on something else that provides some 
> useful security properties.

While it is true that using sips as an indicator of security is useless
(and probably harmful), it is very useful in an AOR as an indicator that
an address is to only be contacted using TLS. It is also useful 
potentially useful to specify that a request is supposed to be sent over

tls end-to-end in a Request-URI.  

The problem with transport=tls were two-fold (as per RFC 3261/26.2.2):
1- It didn't account for TLS over transport other than TCP
2- It only represented a single hop

I think everybody is thinking of "sips" in different context, and that
it
is confusing.

The use of sips in an AORs is quite logical. I really don't see how
we could deprecate that. If I want to only be reachable with TLS
only, I should be able to use sips:[email-masked] as an AOR. I do
not believe that an AOR with a transport parameter is an improvement
(and it is specifically disallowed in RFC 3261). 

However the use of sips gets very confusing when it is used 
in Contacts (and probably other fields as well). In those cases, the
use of transport=tls (and transport=tls-sctp if we defined it) would
probably be much less confusing.

As for Request-URI, I am a little bit on the fence. transport=tls
implies that it is only for a single hop. I'm thinking that when
Request-URI
is an AOR, it could be a sips URI (like when the UA initiates the
session), 
but that routing proxies should only use transport=tls when the select
the
next target for a request URI.

What my draft was trying to do is define exactly what sips would mean in
different contextes, whith as little changes as possible to RFC 3261, so
we wouldn't be completely backward incompatible. Perhaps it highlighting
that it is too complex.

Would people be more comfortable with something along the lines of what
is
described in this email, namely:

1- Reserve the use of sips to AORs (with sip implies sips, but sips
doesn't
   imply sip)
2- Use transport=tls otherwise

I think it would solve the registration problem nicely.  The AOR would
be 
sip unless ONLY sips is supported. 

The Contacts would list explicitely all transport supported
(transport=tls, transport=tcp, transport=udp).

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 18 May 2006 21:56:34 -0400

> it is confusing.

If that is all it does, and use of TLS itself provides no security 
properties, then what is the point? Aside from using more cpu cycles, 
how is using TLS better than using TCP?

Also, if the only point is to indicate use of TLS and a different 
default port, what is wrong with DNSSRV for that?

We don't have SIPT and SIPU for TCP and UDP, so why SIPS for TLS?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 19:15:46 -0700

The one thing that would be nice to preserve out of SIPS -- maybe by 
some other
mechanism -- is the ability for a UAC to _request_ that the proxies do 
their best
to transport things over tls (or what have you, "secure" to my mind is a 
little
nebulous, but others may disagree). Isn't this what proxy-require is 
supposed
to useful for? I believe that I saw somebody propose something like 
that. It
sounds pretty reasonable to me. Proxy-require has the nice property that the
UAC gets to figure out what to do if something goes wrong, and it probably
comports less of the mistaken impression that you can will a proxy into 
doing
something that it may out of malice not want to do.

Obviously transport=tls suffers from the problem that it doesn't convey the
semantic "and thence for ever after". I'm not sure what it's purpose in life
is, but that's most likely just me.

       Mike

Paul Kyzivat wrote:

>> However the use of sips gets very confusing when it is used in 
>> Contacts (and probably other fields as well). In those cases, the
>> session), but that routing proxies should only use transport=tls when 
>> the select
>> the
>> be sip unless ONLY sips is supported.