Subject: [dispatch] HSTS for SIP?

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 5 Apr 2014 21:49:42 +0200

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Is this something we can use in SIP?

How would it work in a proxied network?

Of course a b2bua or SBC can change anything...

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Apr 2014 00:33:49 -0400

> Is this something we can use in SIP?

Perhaps in SIP over websockets.

With SIP over UDP or TCP there would be no way for the server to 
communicate it to the client.

The mechanism we have is DNSSRV, indicating that only TLS is supported.

	Thanks,
	Paul

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 6 Apr 2014 09:13:07 +0200

On 06 Apr 2014, at 06:33, Paul Kyzivat <[email-masked]> wrote:

> With SIP over UDP or TCP there would be no way for the server to communicate it to the client.
Of course we can communicate it in the response, like HTTP, over any transport.
"You should be using TLS for this connection from now on"

Now the question is what it would mean... If the sip outbound connection is over TCP to
the edge proxy and someone beyond that proxy requests TLS, there's not much a UA 
can do. I guess it can be one hop only. 
> The mechanism we have is DNSSRV, indicating that only TLS is supported.
I guess you mean NAPTR.

The idea with HSTS is for a user agent to "remember" that TLS was required for a 
specific target in case a middlebox suddenly changes the DNS record and forces
another target.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Apr 2014 14:30:18 -0400

> "You should be using TLS for this connection from now on"

Oh, I misunderstood in my *very* brief look at the reference.

So you mean that for sip there would be a new header field in some sip 
response that would provide this hint?

>> The mechanism we have is DNSSRV, indicating that only TLS is supported.

Yeah, sorry.

> specific target in case a middlebox suddenly changes the DNS record and forces

ISTM that the usage model it is based on doesn't fit well with sip.
It seems to be predicated on the client being a browser, that has a 
cache of visited web addresses.

Sip doesn't have that. Also, ISTM that proxies totally mess this up.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 6 Apr 2014 20:36:59 +0200

On 06 Apr 2014, at 20:30, Paul Kyzivat <[email-masked]> wrote:

> So you mean that for sip there would be a new header field in some sip response that would provide this hint?
> 
> It seems to be predicated on the client being a browser, that has a cache of visited web addresses.
> 
HTTP did not have a cache on SSL fingerprints or HSTS either, so that's no good argument ;-)

For TOFU - Trust On First use - kind of solutions we will need a cache - if we go down that path. Save known fingerprints and make sure we get the same next time. 

We need to figure out how to apply one or a few of these solutions to SIP clients.

/O

---

From: Michael Procter <[email-masked]>
Date: Tue, 8 Apr 2014 08:14:26 +0100

You could respond to an initial request with a "301 Moved
Permanently", specifying a sips: address instead ;-)  That should
"update any local directories, address books, and user location
caches".

More seriously, one of the reasons an approach like this wouldn't work
is the limited level of support for TLS, combined with a reluctance to
use it sensibly.  I can't be the only person who has seen a UA
configured to use TLS, only use it for the initial INVITE and then
drop back to UDP for in-dialog traffic!

I'm not sure we need new headers/protocol work to get a HSTS-like
feature for SIP, but there may be some useful guidance that could be
issued to help use the pieces we already have.

Michael

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Apr 2014 14:52:39 +0200

> issued to help use the pieces we already have.

We can do a lot to help people who don't read RFCs, but we can't
stop standards development because of them. For those that use TLS, and there
is luckily a growing number (based on customer requests) I think a 
HSTS-like feature would be good to avoid MITM boxes downgrading
connections with a 30x.

No, I haven't seen those boxes yet - but I guess that is a matter of time only.

Well, it was just a thought.
/O

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Apr 2014 12:20:20 -0400

Olle,

I'm generally not understanding the point of this for SIP.
What would it bring that we need and don't already have without it?

	Thanks,
	Paul