Subject: [dane] 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: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Jul 2013 07:57:20 +0200

4 jul 2013 kl. 00:39 skrev "Cullen Jennings (fluffy)" <[email-masked]>:

> 
> 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.
> 
> 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. 

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
> 
> 
> 
> 
> On Jul 3, 2013, at 12:51 AM, Olle E. Johansson <[email-masked]> wrote:
> 
>> Hi!
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Jul 2013 06:19:33 +0000

On Wed, Jul 03, 2013 at 09:51:34AM +0200, Olle E. Johansson wrote:

> 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:

I am confused about the 3rd bullet on slide 9:

	With TLSA public key, match to server by challenge/response
	(ignore server certificate contents).

What is the intent here?  Why is this different from TLSA certificate
or TLSA digest?  It is rather puzzling...  Perhaps the whole validation
slide is a bit mysterious...

On slide 12, indeed DANE aware UAs will match the SRV hostname in
the server certificate unless the certificate usage is 3, in which
case name checks are redundant.  So "3 1 1" can be more compatible
in cases where legacy clients want a different certificate name than
would be the case with DANE usages 0--2.

Thus with no SNI, but TLSA "3 1 1" the certificates can remain
unchanged (slide 13).

-- 
	Viktor.

---

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

On slide 14,

---

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

> slide is a bit mysterious...
Yes, it is. I need to work on that one. :-)

> Thus with no SNI, but TLSA "3 1 1" the certificates can remain
Great.

Thanks for the feedback, I'll take another stab at this and will notify
when I update.

/Olle

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Jul 2013 07:14:17 +0000

On Thu, Jul 04, 2013 at 07:57:20AM +0200, Olle E. Johansson wrote:

> 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.

This is a rather peculiar way of describing TLS, and the picture with
DANE is more complex.

    - The EE certificate is never ignored, the SSL library will use its
      public key to encrypt or authenticate the key agreement.  This is
      not usually described as challenge/response, it is encrypted or
      authenticated key exchange.

      So regardless of which PKI is used to verify the server certificate,
      it is the SSL library's job to ensure that the server certificate
      contains the public key whose private key either signed or decrypted
      the key exchange.

    - If the PKI is DANE, then:

	* If the public key in the TLSA RR is a trust anchor (usage
	  0 or 2), one needs to verify that the server certificate
	  is signed by a valid chain whose top-most element is
	  signed by the public key in question.

	* If the public key in the TLSA RR is an end-entity public key
	  (usage 1 or 3), then it is simply compared with the public
	  key from the server' certificate.  If the usage is 3, that's
	  the only check needed to ensure that the peer is authentic.

    - In principle matching a public key is not substantively
      different from matching a certificate.  And matching via
      digests is conceptually the same as matching complete objects.

      The differences are:

	* The complete object (cert or key) may be too large for reliable
	  delivery via DNS.

	* Matching via digests may require the full object to be sent
	  in-band in the TLS handshake.

	* Support for bare TA public keys (2 1 0) may be difficult with
	  existing libraries when the corresponding cert is not sent
	  in-band.

It sure seems like slide 9 is based on a misunderstanding of RFC 6698,
though perhaps it is simply too concise, and just needs to be stated
more clearly.

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 4 Jul 2013 09:26:53 +0200

> though perhaps it is simply too concise, and just needs to be stated

I think it was sloppy work on the author's behalf. Thank you for your clarification
and - as always - very good feedback.

/O

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Jul 2013 09:07:47 -0700

> 	  signed by the public key in question.

That text could be interpreted as "must be the top-most root CA", which
isn't true.  It may point to an accepted subordinate CA and there may be
a higher level available in a chain.  IE, it doesn't have to be the
upper most endpoint available (though may be the highest endpoint needed
for verification).

Actually, the way that 6698 is written, I think the below is legal usage
of type 0.  But it's not crystal clear:

        O      -- Root CA in a PKIX chain and present in the child's
        |         CA bundle / TA list.
        |
        O      -- type 0/2 DANE record points here to a subordinate TA
        |
        |
        O      -- EE cert

I don't think the reverse is legal:

        O      -- type 0/2 DANE record points here to a subordinate TA
        |
        |
        O      -- Subordinate CA in a PKIX chain and present in the child's
        |         CA bundle / TA list.
        |
        O      -- EE cert

Reading the type 0 specification, I *think* prohibits the second case
because it says:

      "specify a CA certificate, or the public key of such a
      certificate, that MUST be found in any of the PKIX certification
      paths for the end entity certificate given by the server in TLS"

And my reading is that because the type 0 pointer is not *inside* the
PKIX path, then it's not acceptable.  Above it doesn't count if the top
level isn't in the CA store.

Any one else want to point to me where I'm wrong, especially on the
first diagram?

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Jul 2013 09:08:07 -0700

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Jul 2013 18:16:05 +0000

> upper most endpoint available (though may be the highest endpoint needed

That's not the intent, the phrase "a valid chain", means some chain
built from a subset of the certificates sent by the server, hence the
TA may be in the middle, but then we throw away the rest.

>         O      -- type 0/2 DANE record points here to a subordinate TA

Yes, this is just fine.

>         O      -- Subordinate CA in a PKIX chain and present in the child's

This is fine too, but of course the TA in the middle is not
self-signed, or else it can't have an issuing parent.  If the
client's library has trusted intermediate PKIX CAs, this should be
OK also.

>       paths for the end entity certificate given by the server in TLS"

This reading of the language is I believe too strict.  Otherwise
a TA root CA will break on clients that trust intermediate certs,
which would be rather surprising and broken.

All that 6698 was trying to say was the the TA need not be at the
top of the chain.  If the client builds a truncated chain because
it trusts non-root CAs that is not a reason to reject the TA in
usage 0.

OpenSSL typically avoids this problem, because by default it looks
for issuers in the peer's chain first, and in the trust store only
as a last resort (except that the root of the chain is possibly
replaced by a trust-store variant with trust settings).

We should probably clarify this in the ops draft, (it is more
implementation issue than operational issue, but the ops draft
already crosses that boundary in a major way).

> level isn't in the CA store.

This would be rather bad, so if 6698 can be read that way, it should
be made more clear.  Of course if the client only trusts the
intermediate and not the root, the CA constraint is no longer a
constraint, so the client implementation really needs to walk the
chain to the topmost trusted CA and not stop in the middle.

I don't use PKIX validation, so my implementation does not run into
this, but otherwise client care is required.

-- 
	Viktor.