Some thoughts and summary of a discussion of TLS usage in SIP

1. SIPS: must die.
or at least we need to fix TLS usage without the SIPS: uri scheme.
oej@edvina.net - 2016-06-17 v 1.0

2. Example overview
sollentuna.example.com paris.example.com
server to
server connection
(B)
KURT ALICE
UA connection
(A)
UA connection
(B)
Securing first hop
Securing server 2 server
connections
Securing last hop
End to end security
The SIPS: uri scheme is an
attempt to promise end2end
security.

3. The problem
• SIPS: as a URI scheme implies end2end security,
something that can not be verified
• SIPS: promises something that can not really be
delivered, especially complex in a world of b2buas
and gateways to other protocols
• We need more TLS usage, but SIPS: has too many
issues. For some developers, it seems to be the
only solution. This makes TLS less deployed in
code or in usage

4. History
• RFC 3261 talks about TLS usage and certificates
• RFC 5630 clarifies SIPS: URI usage and updates
RFC 3261
• RFC 5922 defines Domain certificates in SIP
• SIPS: is required to implement to be SIP compatible

5. Client certificates
• Never properly discussed
• Needs to match the AOR?
• Needs to match the Contact?
• Needs to match something else?

6. RFC 5630

7. RFC 5630 - general
• 3.1.1. Points to RFC 5626 (Outbound) for UAs in
order to avoid using client certificates (mutual TLS
auth)
• Avoids defining SIP TLS client certificates
• 3.1.3 Discussed best effort TLS
• Points to RFC 3261 section 26.3.2.1 for connection
reuse (and points to RFC 5626)

8. RFC 5630 about
“;transport=tls”
• 3.1.4 :: “The reinstatement of the transport=tls
parameter, or an alternative mechanism for
indicating the use of the TLS on a single hop in a
URI, is outside the scope of this specification.”

9. RFC 5630 about hop-by-hop
security:
• 3.2 :: “The presence of a SIPS Request-URI does
not necessarily indicate that the request was sent
securely on each hop. So how does a UAS know if
SIPS was used for the entire request path to secure
the request end-to-end? Effectively, the UAS
cannot know for sure.”

10. RFC 5630 modification to
3261:
• 4 :: “Because of all the problems described in
Section 3.3, this specification deprecates the last-
hop exception when forwarding a request to the
last hop (see Section 5.3). This will ensure that TLS
is used on all hops all the way up to the remote
target.”
• Which means SIP outbound (RFC 5626) or client
certs for the last hop.

11. RFC 5630 on padlock icons
• Section 4 :: “Some have been tempted to believe
that the SIPS scheme was equivalent to an HTTPS
scheme in the sense that one could provide a
visual indication to a user (e.g., a padlock icon) to
the effect that the session is secured.
This is obviously not the case, and therefore the
meaning of a SIPS URI is not to be oversold. There
is currently no mechanism to provide an indication
of end-to-end security for SIP. “

12. Service owner may control
TLS usage in DNS
• By only presenting TLS in DNS Naptr/SRV the
service owner may limit/enforce UAs to TLS only
• May also implement a policy where TLS is
preferred but TCP/UDP is accepted

13. Where are we?
sollentuna.example.com paris.example.com
server to
server connection
(B)
KURT ALICE
UA connection
(A)
UA connection
(B)
Securing first hop
Securing server 2 server
connections
Securing last hop
Using SIP outbound and TLS we
can secure the first/last hop The user has no way to
affect what happens between
servers or beyond gateways

14. What if we just remove
the SIPS: uri scheme?

15. Remove SIPS:
• Implementations can be SIP compatible without
SIPS:
• We only have control over the FIRST hop, to the
edge server
• What happens beyond that server is no longer in
control (if it ever was)

16. Client side control
• Clients (UAs) implement a “require TLS” option
checkbox in the configuration page, which will
force lookup of NAPTR records, the DNS SRV
records
• If no DNS support, try TLS port 5061
• This only applies to the first hop

17. Requirements
• A way to force clients to use TLS for inbound
connections
• A simple way to reuse that connection for outbound
requests
• Maybe a way to get confidentiality for hops beyond
the proxy
• If so a way to verify that confidentiality

18. Just a thought : S/MIME
• Can we wake up S/MIME again?
• If not, have we analysed the issues with it?
• Any experience?
• There’s some sort of end2end security promise in
that platform.

19. Summary
• In my view, SIPS: is too hard to implement and if
implemented, deliveres a false promise
• TLS edge connections needs to be made more
simple - outbound doesn’t seem to be accepted as
the solution
• We need to look deeper into end2end integrity,
confidentiality and privacy