[sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"

[Olle E. Johansson]

6 jul 2011 kl. 10.23 skrev Martin Hoffmann:

> Olle E. Johansson wrote:
>> 6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
>> 
>>> It's like in HTTP world:
>>> 
>>> - http:// means HTTP over TCP.
>>> - https:// means HTTP over TLS over TCP.
>>> 
>>> Since HTTP just works over TCP, there is no reason for a ;transport
>>> param. But SIP protocol can work over different transport layers (TLS
>>> is not a transport layer).
>>> 
>> You can not compare sips with https. Sorry.
>> 
>> https puts a requirement for TLS all the way.
>> 
>> SIPS: in RFC3261 did not.
> 
> RFC 3261, section 4:
> 
> | A call made to a SIPS URI guarantees that secure, encrypted transport
> | (namely TLS) is used to carry all SIP messages from the caller to the
> | domain of the callee.  From there, the request is sent securely to
> | the callee, but with security mechanisms that depend on the policy of
> | the domain of the callee.
> 
>> It's simply a request, a proposal. Now if you don't want to change the
>> properties of the original request, but still require your
>> infrastructure to use TLS for the next hop you do not want to change
>> to a SIPS: uri, which will put a new requirement for the rest of the
>> signalling. You want to add an attribute like ";transport=tls".
> 
> Why? We are talking about the URI in the (Record-) Route header here,
> which _only_ indicates how to get to the next hop. If you put a SIPS URI
> in there, this has no consequence whatsoever for the complete path.
Because RFC 5630 says that if a Route header has SIPS the contact also has to be SIPS.

   As mandated by [RFC3261], Section 12.1.1:

      If the request that initiated the dialog contained a SIPS URI in
      the Request-URI or in the top Record-Route header field value, if
      there was any, or the Contact header field if there was no Record-
      Route header field, the Contact header field in the response MUST
      be a SIPS URI.


> 
>> Yes, SIPS: is really messy and hard to understand.
> 
> I'd argue it's completely broken like so many things in SIP. IETF went
> out to publish a document to fix it. After much argueing, this became
> RFC 5630 and people are confused as ever.
Agree. It's not complete.

> 
>> How would you guys
>> handle a Contact: with SIPS: ?
> 
> In a dialog or in a registration?
Both.

> 
>> Can you reuse a connection like
>> outbound? I guess not, since you have to verify the endpoint
>> certificate.
> 
> If you reuse a connection you'd have done that already earlier. Most
> likely, the client opened the conneciton to you in the first place.
If the client initiated the connection without a client certificate, you can't reuse that one. If you requested a client cert and that matches the Contact the client provided you with, you are allowed to use it.

> 
> One final word: What Iñaki and me are argueing here is what the standards
> say. What we probably don't agree on is what this means in practice. For
> me as someone who regularly has to bring different SIP implementations
> together, it means pretty much nothing. You'd never find SIPS URIs in
> the wild but plenty of transport=tls. (Or well, not really, nobody is
> using TLS in practice anyways.)

Exactly. And when testing at SIPit (Nils, Daniel and I) we found that most phones doesn't bother with verification of the server cert anyway. Just put a padlock on the screen and be happy - WE ARE SECURE!

/O