I tried to develop my point a little further. I think there should be a way for the UA to specify the means of communication. If we support transport=tls it resembles a little to the transport parameter in the Via header. This is good as long as there single preference. This is always the case in Via header, but the transport parameter is not good enough in the following cases: * Registrations where outbound is not used and user has more than one preference on transport/security attributes. * Outgoing communication and the user has more than one preference on security attributes.
(There are probably other cases which I'm not aware of) These preferences have some relationship with the transport. A UA might want to indicate it supports TLS over TCP and not TLS over SCTP. I think SIPS means - I want to communicate, possibly via trusted proxies, in a manner that a third-party would not be able to intercept or modify. If this definition is acceptable it does not rule out IPSec, despite being out of RFC 3261 scope (I'll open a different thread on that). My point is that this is also part of the possible preferences. A UA might indicate that it can communicate either in IPSec or TLS. In the transport parameter syntax the only option would be a single value such as "transport=ipsec-udp". Furthermore a UA might want to indicate it wants higher grade of security 128 and not 40 bits. I think the draft clarifies well the relationship between SIP and SIPS. If there is a need to handle the cases above, it should be done by other means. Bottom line is that it's likely we'll regret allowing the use of transport=tls. From my understanding the draft tries to add backward compatibility and does not endorse it. > -----Original Message----- > From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 06, 2007 9:27 AM > To: Francois Audet; Paul Kyzivat; Gilad Shaham > Cc: SIP IETF; Dean Willis > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > thoughtsontransport=tls? > > I am strongly against it. If there are any issues that are currently being > solved using transport=tls (in practice), they should be solved in a > different way. > > Regards, > Jeroen > > Francois Audet wrote: > > Normally, I would agree with you. But transport=tls is so > > intertwined with SIPS that I'd rather fix both at the same time. > > > > What I haven't heard is any voice strongly being against the > > re-instatement of transport=tls (except perhaps myself, but I don't > > care anymore: just want to move on). > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, June 05, 2007 16:17 > >> To: Gilad Shaham > >> Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean > >> Willis Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > >> thoughts ontransport=tls? > >> > >> Jumping in. I just happened to pick Gilad's message to respond to. > >> > >> I've only been loosely following this discussion. But it > >> seems to me that this transport=tls issue is a distraction > >> from finishing the sips draft. Why does the sips draft have > >> any responsibility for addressing this issue? > >> > >> I think it would be better to let the sips draft be finished > >> and then move on to addressing all of the (many) important > >> security issues that sips doesn't solve, as a separate effort. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
