Subject: [sipcore] SIP and TLS in the light of Opportunistic Security

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 11 Jan 2015 11:39:12 +0100

Opportunistic Security as defined in RFC 7435 says "Some protection
most of the time". It causes a lot of rethinking. We need to look at this
as well from a SIP perspective. Actually, most of the RFCs doesn't
put a lot of hinders to changing policies in the UAs so that we can
always try TLS and set up connections in an OS way, regardless
if the certificate validates properly or not. 

I have found a few obstacles though:

RFC 3261 says in section 26.3.1:

"   All SIP elements that support TLS MUST also support the SIPS URI
   scheme."

I think it's time to remove the MUST support SIPS URI scheme.
We will need to discuss ";transport=tls" again (as hinted by the latest
SIPit report).

And 26.3.2.1:

"When it receives the TLS Certificate message,
   the UA SHOULD verify the certificate and inspect the site identified
   by the certificate.  If the certificate is invalid, revoked, or if it
   does not identify the appropriate party, the UA MUST NOT send the
   REGISTER message and otherwise proceed with the registration."

In the light of the work on Opportunistic Security (RFC 7435 - Informational)
we can certainly discuss the MUST NOT and SHOULD in 26.3.2.1.
We can certainly set up a TLS session with an invalid certificate, but
should not in any way indicate anything to the user (no locks in the UI!).

What do you think?

/O

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Jan 2015 17:07:48 -0600

On 1/11/15 04:39, Olle E. Johansson wrote:
> as well from a SIP perspective.

Indeed. Thanks for taking the time to kick off this discussion.

> Actually, most of the RFCs doesn't

As part of a larger OE (opportunistic encryption) effort, a slight 
change here probably makes sense. But it wouldn't really be removing the 
MUST; it would be providing a very narrowly scoped exception. Basically, 
we'd be describing another TLS-based mechanism, and changing the 
normative statement you cite just enough to accommodate that new mechanism.

> We will need to discuss ";transport=tls" again (as hinted by the latest

I think you're jumping to mechanism a bit too quickly here. Given the 
nature of OE, I'd prefer it not be something that's particularly visible 
on the signaling path to entities other than those actually 
participating in the TLS session. I certainly don't want to tempt 
someone to render a session as "partially secure," since that's only 
going to encourage the exact kind of risky user behavior that OE 
opponents frequently cite as a key objection.

Also, you really need a design with graceful degradation to plaintext if 
OE is really going to be opportunistic (rather than merely 
unauthenticated), and pre-loading a transport onto a URI doesn't really 
do that (at least, without substantially changing the meaning of the 
"transport" parameter). There are probably other OE-specific 
requirements here, and maybe some SIP-specific requirements as well. We 
would need a more detailed treatment of the topic before we start 
deciding what needs to be changed.

It's possible that doing something similar to "STARTTLS" would work 
here, but we won't know for sure until we work through the requirements.

> And 26.3.2.1...

26.3.2.1 is, in its entirety, subservient to this statement from 26.3.2:

   "While implementers and network
    administrators MAY follow the normative guidelines given in the
    remainder of this section, these are provided only as example
    implementations."

Given this, we don't really need to change 26.3.2.1 at all; we just need 
to clearly explain how a client that would otherwise use an unencrypted 
connection could leverage OE during registration.

/a