Subject: [sipcore] SIPS must die - or at least be able to live without

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 17 Jun 2016 14:57:00 +0200

Friends,

I’ve tried to summarise my thoughts and the feedback in a presentation format.
http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol

Feedback is welcome and I’ll try to keep it up-to-date.

At this point, it’s not very well organised, as I have some more digging to do in regards
of SIP client certs and some other examples of TLS usage in related solutions like
MSRP, SIMPLE etc

It seems we are here:

- We have no agreement to remove SIPS: as a uri scheme, but agree that we need
  to be able to use TLS without it

- There are some thoughts on how to do this without outbound (half-outbound)

- We have not enough ideas on how to replace the SIPS requirement that all
   hops to the UA requiers TLS

- We have no suggestion on how to verify this

I return to S/MIME - what happened to that?

With the new thoughts about certificate handling used in WebRTC for DTLS and in Email for S/MIME using Dane
there may be some ideas to look at.

Personally I think removing SIPS: from the SIP set of standards would be a good thing. :-)

/O

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 17 Jun 2016 09:18:14 -0400

>   to be able to use TLS without it

RFC5630 covers the use of SIP scheme over TLS already:
https://tools.ietf.org/html/rfc5630#section-3.1.3

>    hops to the UA requiers TLS

Why would you do that?

Regards,
 Rifaat

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 17 Jun 2016 15:21:07 +0200

> On 17 Jun 2016, at 15:18, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jun 17, 2016 at 8:57 AM, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> Friends,
> 
> http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol <http://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol>
> 
> https://tools.ietf.org/html/rfc5630#section-3.1.3 <https://tools.ietf.org/html/rfc5630#section-3.1.3>
> 
And leave some gaps that I documented in my presentation… As I say on one slide
this RFC points to RFC 5626 but no one seems to want to implement it so it’s not
the solution. Check the presentation!

>    hops to the UA requiers TLS
Well, some people on this list pointed that out as a feature they wanted
when I said that I just wanted to remove it so I’ll let them respond.

/O
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jun 2016 11:13:43 -0400

> I return to S/MIME - what happened to that?

I remember back when I was first learning about SIP (with RFC2543) I 
spent some effort trying to understand the S/MIME stuff. I was never 
able to figure out how it could possibly work. After asking a few 
questions I finally stopped thinking about it.

> Personally I think removing SIPS: from the SIP set of standards would be a good thing. :-)

The one thing SIPS offers is a way to indicate a *requirement* by the 
UAC for security on every hop. Unfortunately the realization of that 
hasn't worked out.

I suppose the same thing could be achieved using Require and 
Proxy-Require. But still there is no obvious way to verify it has been 
honored.

I think I recall at one time there was a proposal for how to establish 
an e2e TLS association. But nothing came of it. Maybe something could be 
worked out that way. For instance, if webrtc can succeed in establishing 
an e2d DTLS connection for media, why can't the same be done for sip? 
And if it can be done for media, why couldn't it also be done for 
signaling?

For instance, use SIP to establish a session, with ICE used to establish 
an RTCWEB data channel. Then do further signaling over the data channel. 
Use that to establish other media streams.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 17 Jun 2016 17:25:32 +0200

> On 17 Jun 2016, at 17:13, Paul Kyzivat <[email-masked]> wrote:
> 
> I remember back when I was first learning about SIP (with RFC2543) I spent some effort trying to understand the S/MIME stuff. I was never able to figure out how it could possibly work. After asking a few questions I finally stopped thinking about it.
Oh yeah, I’ve been struggling with RSA lawyers and understanding it a long time ago. The difference is that there’s
a bit more code out there now and a little - although not much - more experience in usage of it e-mail.

> The one thing SIPS offers is a way to indicate a *requirement* by the UAC for security on every hop. Unfortunately the realization of that hasn't worked out.
> 
> I suppose the same thing could be achieved using Require and Proxy-Require. But still there is no obvious way to verify it has been honored.
> 
> I think I recall at one time there was a proposal for how to establish an e2e TLS association. But nothing came of it.
Yep, some sort of websocket-like upgrade - I do remember there was such a draft too.

> Maybe something could be worked out that way. For instance, if webrtc can succeed in establishing an e2d DTLS connection for media, why can't the same be done for sip? And if it can be done for media, why couldn't it also be done for signaling?
> 
> For instance, use SIP to establish a session, with ICE used to establish an RTCWEB data channel. Then do further signaling over the data channel. Use that to establish other media streams.
That’s one idea :-)

/O

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Jun 2016 20:03:22 +0000

Hi,

...

>I think I recall at one time there was a proposal for how to establish an e2e TLS association. But nothing came of it. Maybe something could be worked out that way. For instance, if webrtc can succeed in >establishing an e2d DTLS connection for media, why can't the same be done for sip? 
>And if it can be done for media, why couldn't it also be done for signaling?

Because SIP is not an e2e protocol: intermediaries need to have access (read: decrypt) signalling information.

>For instance, use SIP to establish a session, with ICE used to establish an RTCWEB data channel. Then do further signaling over the data channel. 

...or, as it it's also known as: H.245 :)

But, the question is WHAT information you want to protect.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jun 2016 17:39:19 -0400

> But, the question is WHAT information you want to protect.

Yes, that is important to decide.

Normal users most likely want media protected, at least.

Next, I suppose many people would like "call metadata" protected. Almost 
nothing we will do will protect that. I guess SIP over TOR perhaps. 
(Though it seems TOR isn't safe either.)

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 17 Jun 2016 18:08:19 -0400

> Normal users most likely want media protected, at least.

The best way to protect media is DTLS-SRTP. The media will be protected
even if signaling is compromised (as long as it is correctly authenticated).

> nothing we will do will protect that. I guess SIP over TOR perhaps. (Though
> it seems TOR isn't safe either.)
>

There is also the issue of end-to-end authentication of signaling. It is
not only important to protect the information but it is also important to
make sure that session description and the user identity was not tempered
with. In some sense this problem is exactly the same as identity issues
which are part of WebRTC.

I guess the most important issue I see with this discussion is definition
of scope. SIP can be the end point communication protocol or federation
protocol between service providers. SIP over TLS with certificate based
authentication is perfect for communicating between different services
located on public IP (federation). It will work quite well if you need to
terminate a SIP call to a PSTN provider or accept a PSTN call to a VoIP
service.

SIP is a horrible protocol for end points with or without TLS. It tries to
enable the operations of 12-button VoIP phones, but manages to be broken
for almost any feature. Security, NAT traversal, presence, distinctive
ringing, MWI, etc all seems to be broken in almost all practical
implementations. I hope these ancient phones will die together with SIP on
the end points and get replaced by WebRTC based implementations. I just do
not see why would anybody at this point build a new SIP end point device
instead of making something browser based. At this point I would use a push
service, such as FireBase Messaging (
https://firebase.google.com/docs/cloud-messaging/) instead of registrations
to notify about incoming calls or presence related updates, WebRTC for real
time media and dynamic HTML for UI. This will be easier to build, will
provide better feature set, scale better, be a lot more secure and use less
power on mobile.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 18 Jun 2016 03:31:40 +0000

“There is also the issue of end-to-end authentication of signaling. It is not only important to protect the information but it is also important to make sure that session description and the user identity was not tempered with. In some sense this problem is exactly the same as identity issues which are part of WebRTC.”

You hit the nail on the head. The assumption of “secure end-to-end signaling” (use of fingerprint attribute)  is a prerequisite for DTLS-SRTP to be meaningful from security perspective.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Friday, June 17, 2016 6:08 PM
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] SIPS must die - or at least be able to live without

On Fri, Jun 17, 2016 at 5:39 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 6/17/16 4:03 PM, Christer Holmberg wrote:
But, the question is WHAT information you want to protect.

The best way to protect media is DTLS-SRTP. The media will be protected even if signaling is compromised (as long as it is correctly authenticated).

Next, I suppose many people would like "call metadata" protected. Almost nothing we will do will protect that. I guess SIP over TOR perhaps. (Though it seems TOR isn't safe either.)

There is also the issue of end-to-end authentication of signaling. It is not only important to protect the information but it is also important to make sure that session description and the user identity was not tempered with. In some sense this problem is exactly the same as identity issues which are part of WebRTC.

I guess the most important issue I see with this discussion is definition of scope. SIP can be the end point communication protocol or federation protocol between service providers. SIP over TLS with certificate based authentication is perfect for communicating between different services located on public IP (federation). It will work quite well if you need to terminate a SIP call to a PSTN provider or accept a PSTN call to a VoIP service.

SIP is a horrible protocol for end points with or without TLS. It tries to enable the operations of 12-button VoIP phones, but manages to be broken for almost any feature. Security, NAT traversal, presence, distinctive ringing, MWI, etc all seems to be broken in almost all practical implementations. I hope these ancient phones will die together with SIP on the end points and get replaced by WebRTC based implementations. I just do not see why would anybody at this point build a new SIP end point device instead of making something browser based. At this point I would use a push service, such as FireBase Messaging (https://firebase.google.com/docs/cloud-messaging/) instead of registrations to notify about incoming calls or presence related updates, WebRTC for real time media and dynamic HTML for UI. This will be easier to build, will provide better feature set, scale better, be a lot more secure and use less power on mobile.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Jun 2016 10:35:13 -0400

On 6/17/16 11:31 PM, Asveren, Tolga wrote:
> “There is also the issue of end-to-end authentication of signaling. It
> is not only important to protect the information but it is also
> important to make sure that session description and the user identity
> was not tempered with. In some sense this problem is exactly the same as
> identity issues which are part of WebRTC.”
>
>
>
> You hit the nail on the head. The assumption of “secure end-to-end
> signaling” (use of fingerprint attribute)  is a prerequisite for
> DTLS-SRTP to be meaningful from security perspective.

For the common telephony use cases it is going to be tricky to figure 
out what we mean here. It only really works e2e if the calling and 
called endpoints possess unique credentials known to both. Otherwise, 
one way or another you are relying on transitive trust.

For instance, when I call the Acme Bank, I probably don't know exactly 
who I am calling or have a credential for them. Every worker at the bank 
could have the bank's credential that I know, but that is difficult to 
administer. Otherwise I'm relying on transitive trust between a server 
at the bank that has those credentials, and the worker's UA.

Note that Webrtc relies on transitive trust between the two ends to 
relay the fingerprints, via at least one server in the middle. And just 
like with SIP, there is no guarantee that signaling on each leg is 
protected.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 19 Jun 2016 00:47:25 +0000

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Saturday, June 18, 2016 10:35 AM
> To: Asveren, Tolga <[email-masked]>; Roman Shpount
> <[email-masked]>
> Cc: [email-masked]
> > was not tempered with. In some sense this problem is exactly the same
> > as identity issues which are part of WebRTC.”
> >
> >
> >
> For the common telephony use cases it is going to be tricky to figure out
> what we mean here. It only really works e2e if the calling and called
> endpoints possess unique credentials known to both. Otherwise, one way or
> another you are relying on transitive trust.
> 
> For instance, when I call the Acme Bank, I probably don't know exactly who I
> am calling or have a credential for them. Every worker at the bank could have
> the bank's credential that I know, but that is difficult to administer.
> Otherwise I'm relying on transitive trust between a server at the bank that
> has those credentials, and the worker's UA.
> 
> Note that Webrtc relies on transitive trust between the two ends to relay the
> fingerprints, via at least one server in the middle. And just like with SIP, there
> is no guarantee that signaling on each leg is protected.
[TOLGA] I didn’t mean to imply that WebRTC+DTLS/SRTP solves any problem, to the contrary, it does not change anything fundamentally as far as the need for "end-to-end security/identity verification for signaling" is concerned. 
Use/trust on "fingerprint" does not necessarily imply "Identity verification", it merely serves the purpose of verifying that the certificate used for DTLS connection can be trusted on -as it is not signed by a CA-. And actually, if one takes things a bit more to philosophical level, isn’t even use of a CA "a transitive trust relationship"? How can I *really* trust a particular CA? They may (and actually it is a well-known fact that they are doing this in certain countries) issue certificates for Company-A to be used by some other entity. I think the only way I can trust the identity on a certificate is if there is a 1:1 relationship between verified identity/corresponding CA. For example, Alex provides Bob his personal CA information (by whatever secure means, maybe handing it over in a diner) and Bob knows that this particular CA can be relied on only to verify identity=Alex.
ZRTP would provide confidentiality but still would need end-to-end secure signaling from identity perspective.
So, overall, the problem in front of us is a though nut to crack...

---

From: Roman Shpount <[email-masked]>
Date: Sun, 19 Jun 2016 21:28:02 -0400

On Sat, Jun 18, 2016 at 8:47 PM, Asveren, Tolga <[email-masked]>
wrote:

> [TOLGA] I didn’t mean to imply that WebRTC+DTLS/SRTP solves any problem,
> to the contrary, it does not change anything fundamentally as far as the
> need for "end-to-end security/identity verification for signaling" is
> concerned.
> Use/trust on "fingerprint" does not necessarily imply "Identity
> verification", it merely serves the purpose of verifying that the
> certificate used for DTLS connection can be trusted on -as it is not signed
> by a CA-. And actually, if one takes things a bit more to philosophical
> level, isn’t even use of a CA "a transitive trust relationship"? How can I
> *really* trust a particular CA? They may (and actually it is a well-known
> fact that they are doing this in certain countries) issue certificates for
> Company-A to be used by some other entity. I think the only way I can trust
> the identity on a certificate is if there is a 1:1 relationship between
> verified identity/corresponding CA. For example, Alex provides Bob his
> personal CA information (by whatever secure means, maybe handing it over in
> a diner) and Bob knows that this particular CA can be relied on only to
> verify identity=Alex.

I just wanted to clarify what I've said earlier: There are two related but
separate problems:

1. End-to-end encryption. This means end to end protection of metadata

2. End-to-end authentication. This means that signaling information, such
as user metadata, destination addresses, ICE ufrags, and DTLS fingerprints
have not been modified.

Neither problem can be resolved without trusted third parties. If there is
a third party that both clients trust and with which both can authenticate
themselves, both problems can be resolved. There are some partial solutions
available without trusted third parties, but they can typically be
circumvented. In general, end-to-end authentication is a simpler problem to
solve, since all it requires is a third party, which both end points trust
that can generate a signature for the sensitive information, as well as a
mechanism to pass this signature through the signaling exchanges.

Regards,
_____________
Roman Shpount