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

From: "Francois Audet" <[email-masked]>
Date: Thu, 18 May 2006 21:13:06 -0500

> > 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).
> 
> 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?

I don't see what is so difficult to understand here.

If you know me from my AOR sips:[email-masked], it basically means that
you need to use TLS to send requests. Proxies in the middle are also
then
supposed to use TLS.

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

There is nothing wrong with that. But there are cases where you can't
use
it: sips:[email-masked];user=phone is one example.

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

We do have http and https however.

Backtracking a little: our goal is NOT to completely change RFC 3261. We

have a responsibility to make sip work with TLS, preferably in a way
that
is least disruptive as possible to the our customers, i.e., the people
who
use our specs.

Telling them exactly the opposite of what we told them in RFC 3261 is
not
the right way to do it...

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 18 May 2006 19:19:06 -0700

>the right way to do it...
If we told them that SIPS was "secure" in any way that's even vaguely 
similar
to https, then we were mistaken, and we should cut our losses as soon as 
possible.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 May 2006 00:39:15 -0400

>> We do have http and https however.

Yes we do. The *only* value of https over http is that provides that I 
will have a secure connection with the a server that is authorized to 
use that name.

> to https, then we were mistaken, and we should cut our losses as soon as 

Without that guarantee, what is the point?

I guess we still have the indication that the target of the URI 
*requires* that a secure communication path be used to reach it. But if 
we lack a way to deliver on the guarantee, it is an empty one.

In some environments based on transitive trust, *maybe* hop by hop 
security and an understanding that a server with credentials for the URI 
actually received the request (even though it may have passed it on) is 
enough of a guarantee.

I guess the existing rules in 3261 are based on an assumption like that, 
though it obviously isn't so clear. One thing that is lacking there is a 
clear definition of scope of transitive trust.

	Paul