[dispatch] SIP, TLS and oppurtunistic encryption

["Olle E. Johansson" <[e-mail]>]

Hi!

Paul Hoffman has written a document that defines "Oppurtunistic Encryption" in regards to TLS and separates this from unauthenticated sessions. It's a good read. (and discussed in the UTA wg)

http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00

This got my head busy with applying this to SIP. 

In SIP we already have a kind of oppurtunistic encryption where the user has not required a confidential session. If a service sets up NAPTR records and SRV ONLY indicating and supporting TLS and _sips there's no choice for a SIP implementation than to set up a TLS connection. The user is not involved and a phone should propably not indicate a lock. The first hop may or may not be TLS, if there is a proxy in the middle.

If we follow the thinking in Paul's document and configure a SIP client to always look for and try to use TLS by using DNS or simply trying a connection to port 5061 before anything else, then we have oppurtunistic encryption again. Regardless of SIP uri scheme and ;transport headers.

Should the via headers signal TLS or TCP in this case? We use TLS for authenticated and in some cases encrypted SIP signalling. The use of "TLS" in the via adds requirements on authentication on the response path back. Can a proxy add something to the Record-route header to indicate that it supports TLS if the other end wants to use it - in order to speed up the process?

If we assume we should use "TCP" in the via - should we somehow record that we actually used TLS?

Like every other area in the IETF we need to focus on responding to the attack on the Internet. Adding oppurtunistic encryption in our applications seems like a good thing, but it should not cause unexpected behaviour.

/O