Subject: [dispatch] Random thoughts about SIP and DANE

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 3 Jul 2013 09:51:34 +0200

Hi!

I've tried to collect my thought about SIP and DANE on a slide set. It's the way I brainstorm I guess :-)

You can view it here:
http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protocol

Feedback is always welcome! 

If this is on the right path, I'll try to write a draft.

We do have DNSsec support in Kamailio now, so hopefully I can get the developer team to work with me to get some code for testing.

/Olle

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Jul 2013 14:17:01 +0200

> Feedback is always welcome!

Just some comments:

Slide 13
------------

According to RFC 5922:

- First check subjectAltName for SIP URIs with no username@. If so
take them and exit.
- Otherwise check subjectAltName for DNS domains. If so take them and exit.
- Otherwise check the CN.

Slide 14
-----------

SIPS? No please... it's better to write a new draft deprecating SIPS schema ;)

SIMPLE? good luck! :)

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jul 2013 22:39:33 +0000

I like it. Hope you write a draft. 

In slide 9 with pub key, I don't understand how the challenge / response works but this is probably just me not knowing enough…

On slide 14, 

SIPS has turned out to be a mess but I don't think think you have to consider it one way or the other. As much as it works (or does not work), a connection secured via the DANE approach can be treated the same as a connection secured via classic TLS approach… I suspect this is about the same answer for connection reuse and SIMPLE. It seems like they should both work fine with this. 

SIP Identity is a different kettle of fish but I think that as long as the STIR bof deals with DANE, hopefully that will be resolve with something better than current SIP Identity RFC. 

On Jul 3, 2013, at 12:51 AM, Olle E. Johansson <[email-masked]> wrote:

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Jul 2013 07:57:20 +0200

> I like it. Hope you write a draft. 
Thanks.
> In slide 9 with pub key, I don't understand how the challenge / response works but this is probably just me not knowing enough…
TLS verifies that the server actually has the private key in the cert it sends using a challenge/response mechanism. If you ignore the cert (since you actually have the public key and trust it), you still want to verify that the server has the matching private key.
> SIPS has turned out to be a mess but I don't think think you have to consider it one way or the other. As much as it works (or does not work), a connection secured via the DANE approach can be trea…

Yes. There are some questions in regards to certificate matching in SIMPLE but that applies regardless of DANE.
> SIP Identity is a different kettle of fish but I think that as long as the STIR bof deals with DANE, hopefully that will be resolve with something better than current SIP Identity RFC. 
Well, Jon wrote on the STIR mailing list that the HTTP uri could be ignored if you had other means of verifying the cert, so if that's correct the issue is already solved.

Thanks for your feedback, Cullen!

/O