[SR-Users] NAPTR, SRV and sips vs. transport=tls

[Olle E. Johansson]

11 dec 2012 kl. 01:39 skrev Juha Heinanen <jh at tutpro.com>:

> Iñaki Baz Castillo writes:
> 
>> transport=tls has NEVER been real, no one RFC mentions it.
> 
> transport=tls is very real. many sip UAs and proxies support it.
The interesting part was that it was deprecated in the text of RFC 3261, but never existed.
And yes, it solves a problem that we can't solve without it, so everyone implements it.

> 
> funny that you now care about RFCs, when in the same message you don't
> care about them regarding sips.

RFC 3261 description of the SIPS: uri scheme was kind of naive, and did not work in
practise. RFC 5630 did a good job in trying to clarify the mess. Most SIP people agree
that it's still not really resolved. SIPS: doesn't deliver the same promise as HTTPS  -
security end to end. SIPS: just guarantees the first hop.

In addition there is a lot of missing pieces to get SIPS: to work. LIke how a proxy
can signal back to the originating UA that it could not set up a TLS connection because
the certificate of the next hop was bad/expired/not signed by approved CA or something else.

After ten years, I think SIPS as a uri scheme is a lost cause. This does NOT mean that
TLS is a lost cause, but I think we can't leave the decision about security to the end point
user - and they can't decide whether or not they want to place a request for  "secure signalling" in their
call setup. The WebRTC way is better, just make every call more secure.

/O