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

["Olle E. Johansson" <[e-mail]>]

On 26 Jan 2014, at 13:34, Michael Procter <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>> 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
> 
> 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.
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).

> 
> 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.
This re-adds SANs that I wanted to remove ;-)
> 
> 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.
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
> 
> Best regards,
> 
> Michael