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

[Iñaki Baz Castillo]

2011/7/6 Martin Hoffmann <martin.hoffmann at telio.ch>:
>> Main cause of the confussion ever after RFC 5630, is the fact that
>> such RFC does not want to cover the ;transport=tls case in deep (which
>> exists anyway as RFC 2543 and RFC 3261 mention it).
>
> Why would it need to. There is _no_ transport=tls in 2543 and 3261 says
> explicitely "don't use it; we just kept it in to stipulate long-winded
> future discussions" (already it doesn't say the latter bit). The purpose
> of 5630 was to explain the whole SIPS thing. Obviously, it failed.
>
> Just to repeat it once more (because this is fun): The use of the value
> "tls" for the transport URI parameter has never been mandated by any SIP

After re-checking RFC 2543 and RFC 3261:


- In RFC 2543 "sips" schema does not exist, neither ";transport=tls".
The only it says is that a request can be sent via TLS by setting
"TLS" as Via transport:

  RFC 2543  -  13.1.4 Hop-by-Hop Encryption

   SIP requests and responses MAY also be protected by security
   mechanisms at the transport or network layer. No particular mechanism
   is defined or recommended here. Two possibilities are IPSEC [34] or
   TLS [35].


- In RFC 3261 "sips" schema is defined and mandates SIP over TLS over
TCP (as neither SCTP over TLS or DTLS were defined in 2002, but leaves
the door open for using new secure mechanism when schema is "sips").


- RFC 3261 shows *NO* example of ";transport=tls", not al all, and it
clearly states that "sips" must be used.


- RFC 3261 just talks about "tls" in ;transport param in the BNF section:
    transport-param   =  "transport="  ( "udp" / "tcp" / "sctp" / "tls"
                                                        / other-transport )

and this is becase, as RFC 5630 explains:

  The "tls" parameter has not been eliminated from the ABNF in
  [RFC3261], Section 25, since the parameter needs to remain in the
  ABNF for backward compatibility in order for parsers to be able to
  process the parameter correctly.  The transport=tls parameter has
  never been defined in an RFC, but only in some of the Internet drafts
  between [RFC2543] and [RFC3261].


- And RFC 3261 says:

      The use of
      "transport=tls" has consequently been deprecated, partly because
      it was specific to a single hop of the request.  This is a change
      since RFC 2543.

  but in RFC 2543 there is no mention AT ALL to ";transport=tls",
neither "tls" is
  mentioned as a valid value for the URI transport param. In fact, BNF
in RFC 2543 says:

     transport-param = "transport=" ( "udp" | "tcp" )



So after "re-reading" all the specifications (RFC 2543, RFC 3261 and
RFC 5630) it's fully CLEAR for me that using ;transport=tls is
*incorrect*. It seems that such value has been used in some draft
between RFC 2543 and RFC 3261 (without including them!!). But since
RFC 3261 (which is what we use) there is no ;transport=tls at all. So
implementations should leave using it (because they are using
something that does not exist).

Now it somebody still thinks that ;transport=tls is valid, he should
at least point to any alive specification showing it :)



-- 
Iñaki Baz Castillo
<ibc at aliax.net>