Subject: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation

From: Michael Procter <[email-masked]>
Date: Sat, 25 Jan 2014 22:40:32 +0000

Hi Olle,

I have read your draft on DANE for SIP, and have a question about
section 8.  The section starts with the statement:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate using RFC 5922 rules.

I'm not sure we want to use the SRV hostname here.  RFC 5922 uses the
original domain before the NAPTR lookup (the AUS) which is probably
the same as the SRV hostname, but may be different[0].

I think we have to keep the mechanisms aligned to ensure that a
certificate that matches under RFC 5922 rules continues to match after
you add a TLSA RR.

Best regards,

Michael

[0] RFC 3263 Section 4.1, para 10 starts:
   It is not necessary for the domain suffixes in the NAPTR replacement
   field to match the domain of the original query (i.e., example.com
   above).

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 26 Jan 2014 08:53:32 +0100

> certificate that matches under RFC 5922 rules continues to match after
One of the reasons to change to host name was to simpify hosting. Having
the domain name in the certificate is not a good thing, especially not for sites
that have a large number of domains (hosting). It's well documented
in a few of the DANE drafts. With DNSsec the binding between a domain
and a host is assured by the signed records. The binding between a host
and a service in TLS is assured by the certificate and signed TLSA record.
The authority to serve a domain is assured by DNSsec and the identity
of the host is checked in TLS.

Without DNSsec we need a secure binding between the certificate and
the domain and mix authorization and identification in the same
operation. As stated, this is not seen as a good solution today.

You can still have a certificate that matches both standards, with the
host name in the CN and domains in the SAN if you want. A client
compliant with this specification will look for the host name (SRV host)
in the CN and a client following the SIP domain cert RFC will ignore
the CN and only look into the SAN fields.

Thanks for the feedback!
/O

---

From: Michael Procter <[email-masked]>
Date: Sun, 26 Jan 2014 12:34:13 +0000

Rather than saying in section 8 that clients validate the certificate
"using RFC 5922 rules", it might be clearer to explicitly call out
which part of the RFC should be used.  Maybe something like:

   The client MUST
   determine the SIP domain identities in the server certificate using
   the procedure in Section 7.1 of RFC 5922.

   o  If there were no identities found in the server certificate, the
      server is not authenticated.

   o  If the domain extracted from the AUS matches any SIP domain
      identity obtained from the certificate when compared as described
      in Section 7.2 of RFC 5922, the server is authenticated for the domain.

(Text borrowed from RFC 5922 section 7.3 with light edits)

But that doesn't seem to agree with this statement:

On 26 January 2014 07:53, Olle E. Johansson <[email-masked]> wrote:
> A client
> the CN and only look into the SAN fields

RFC 5922 doesn't let you do that.  Section 7.1 bullet 2 states that
you may only examine the CN if there are no subjectAltNames present
(not just no matching subjectAltNames).  It also only permits you to
use a DNS name when there are no SIP URIs listed.

You might be better off not using any of the RFC 5922 rules at all!
Removing the RFC5922 references from the first paragraph of section 8
makes it look like:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate.  A DANE-capable
   SIP implementation looks for the SRV hostname in the list of
   SubjAltName DNSName extension fields.  Only if there are no
   SubjAltName extension fields may the client look in the CN of the
   X.509 certificate.

That approach (not mentioning RFC 5922) seems to make sense and still
defends against the attack outlined in draft-ietf-dane-srv-03 section
10.3.

Best regards,

Michael

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 26 Jan 2014 13:50:46 +0100

> use a DNS name when there are no SIP URIs listed.
Right. My example was a way to produce one certificate for both. I wanted
to totally ignore the SANs in SIPDANE. A certificate with ONLY one
CN and NO SANs will collide as you say. That needs to be mentioned.
In that case SNI may help (if we come up with a draft for SIP and SNI).

>   SubjAltName extension fields may the client look in the CN of the
This re-adds SANs that I wanted to remove ;-)
> defends against the attack outlined in draft-ietf-dane-srv-03 section
I will check that part again and possibly come back with more questions.
And remove some references to 5922 to avoid confusion. There was questions
earlier about backwards compatibility and that may be moved into a separate section.

Thanks again,
/O