Re: [dane] DANE-SRV, SNI functional equivalent and XMPP

[Viktor Dukhovni <[e-mail]>]

On Tue, May 19, 2015 at 08:07:23AM -0700, Peter Saint-Andre - &yet wrote:

> >    SRV is insecure:  The reference identifiers SHALL include the service
> >       domain and MUST NOT include the SRV target server host name (e.g.,
> >       include "im.example.com" but not "xmpp23.hosting.example.net").
> >       The service domain is the preferred name for TLS SNI or its
> >       equivalent.
> >
> >    SRV is secure:  The reference identifiers SHALL include both the
> >       service domain and the SRV target server host name (e.g., include
> >       both "im.example.com" and "xmpp23.hosting.example.net").  The
> >       target server host name is the preferred name for TLS SNI or its
> >       equivalent.
> >
> >I think we can all agree that when SRV is insecure, the client doesn't
> >have a strong binding or "association" (using language from
> >draft-ietf-xmpp-dna) of the service domain to the target server host
> >name, so it needs to use the service domain as the reference identifier.

I disagree.  What's missing here, is any dependence on the existence of
the associated TLSA records, and client support for DANE (else client
would not have checked the TLSA records).

When SRV is secure, the client proceeds to check TLSA RRs, otherwise
it does not, and reverts to non-DANE behaviour inluding any legacy
behaviour for choosing the SNI name.

When SRV is secure *AND* TLSA records are found, the client MUST
use the TLSA base domain as the SNI name, and MUST look for that
domain in the server certificate.  Non-DANE servers will not have
TLSA records, so they are not affected.  The client will also for
compatibility with legacy certificate deployments tolerate the
service domain as a name in the peer certificate.

See the DANE OPS draft description of the redirection use-cases.
Also compare with the SMTP draft.

> >When SRV is secure, the client does have that kind of strong binding or
> >association, so it is OK for the client to seek a match against both the
> >target server host name and the service domain when checking the
> >identifiers in the certificate.

No.  This binding along is not enough.  The server needs to also publish
TLSA records to signal that support for DANE TLS (with secure redirection)
is supported by the server.

> NEW
>    SRV is secure:  The reference identifiers SHALL include both the
>       service domain and the SRV target server host name (e.g., include
>       both "im.example.com" and "xmpp23.hosting.example.net").  The
>       service domain is still the preferred name for TLS SNI or its
>       equivalent (this reduces code complexity and the possibility of
>       interoperability problems).

I object.  The fix is to delay the decision until the presence of
TLSA records has been checked.

-- 
	Viktor.