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

From: Kim Alvefur <[email-masked]>
Date: Sun, 17 May 2015 18:55:29 +0200

Hello list!

Georg Lukas noted that section 4.1 says, in the context of XMPP, to use
to='xmpp23.hosting.example.net' in the stream header, as that is the
"functional equivalent" of SNI in XMPP.  However, that conflicts with
the current semantics of 'to' being the service domain name to the
server host name.  That will break many, if not all, deployed servers.
The server should know what certificate to use for the indicated domain
name.

http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1

-- 
Kim "Zash" Alvefur

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 18 May 2015 15:03:54 -0700

> Hello list!

Hi Zash!

> http://tools.ietf.org/html/draft-ietf-dane-srv-14#section-4.1

Hmm.

First, all draft-ietf-dane-srv says is that you don't need to use SNI in 
XMPP because we already have a way for the TLS client to specify which 
domain name it expects of the TLS server, i.e., the 'to' address of the 
initial stream header.

Second, draft-ietf-xmpp-dna is the document that specifies the behavior 
of XMPP entities. So IMHO this is a topic for the XMPP WG list, not the 
DANE WG list. I'll forward this message to that list and continue the 
conversation there. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Kim Alvefur <[email-masked]>
Date: Tue, 19 May 2015 13:45:17 +0200

> domain name it expects of the TLS server, i.e., the 'to' address of the

What I tried to say was that this sentence in the draft is confusing
and/or wrong in the context of XMPP:

SRV is secure: [...] The target server host name is the preferred name
for TLS SNI or its equivalent.

> conversation there.

Right, dane-srv doesn't have authority over XMPP specifics.

Thanks :)

-- 
Kim "Zash" Alvefur

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 19 May 2015 07:46:11 -0700

> for TLS SNI or its equivalent.

Ah, I see.

I think this might be a more generic issue. For context from §4.1, 
here's the complete text:

    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.

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.

Currently, this document states that when SRV is secure, it is preferred 
for the client to indicate to the server that its reference identifier 
is the target server host name. (We're assuming that the purpose of the 
SNI or equivalent is to indicate the client's preferred reference 
identifier.) If that's wrong for XMPP (and I'm not yet convinced that it 
is), is it potentially wrong for other application protocols, or even 
for all application protocols in general?

Given that the client can indicate only one reference identifier via SNI 
or equivalent, yet we're saying that the client actually has two 
reference identifiers in this case, I wonder whether the best general 
advice is for to *indicate* the service domain but *accept* both the 
service domain and the target server host name.

I'll check with my co-author on that to see what he thinks, but feedback 
from others on the list would be appreciated.

> Right, dane-srv doesn't have authority over XMPP specifics.

Sure, let's discuss those specifics (if any) on the XMPP WG list - but 
see above on whether this might be a generic issue.

Thanks for the feedback!

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 19 May 2015 08:07:23 -0700

> from others on the list would be appreciated.

OK, Matt Miller and I chatted about this over a secure IM protocol.

We're both thinking that it's best to always *indicate* the service 
domain in the SNI or equivalent but *accept* both the service domain and 
the target server host name during identity checking. Always indicating 
the service domain minimizes code complexity and reduces the possibility 
of something going horribly wrong if the client (or underlying DNS 
library) thinks that SRV is secure when it really isn't.

I suggest the following text change:

OLD

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

Given that this document has already been approved for publication, we 
will need to check this change with Stephen Farrell, the responsible 
Area Director.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 May 2015 23:24:14 +0000

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

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

>       interoperability problems).

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

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 19 May 2015 19:46:07 -0700

> TLSA records has been checked.

Viktor, the text in question is from §4.1, which begins as follows:

    4.1.  SRV Records Only

    If the client received zero usable TLSA certificate associations...

The whole point of §4.1 is to address the case where we have SRV records 
and no usable TLSA records. Naturally, the client can't know that it has 
no usable TLSA records "until the presence of TLSA records has been 
checked" as you say. I'd agree with you if we were proposing to change 
text in §4.2, but we're not, so I don't see the force of your objection.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 20 May 2015 08:04:04 +0000

On Tue, May 19, 2015 at 07:46:07PM -0700, Peter Saint-Andre - &yet wrote:

[ Sorry, I'm on the road, and cycles are limited.  ]

> Viktor, the text in question is from ?4.1, which begins as follows:
> 
>    4.1.  SRV Records Only
> 

In that case, this is a pure legacy use-case, and no incompatible
behaviour should be introduced.

> The whole point of 4.1 is to address the case where we have SRV records and
> no usable TLSA records. Naturally, the client can't know that it has no
> usable TLSA records "until the presence of TLSA records has been checked" as
> you say. I'd agree with you if we were proposing to change text in 4.2, but
> we're not, so I don't see the force of your objection.

I did not get a chance to read the text in context.  Adding the target name
as a secondary indentifier is fine, but indeed the SNI name should not
change absent signalling via TLSA RRs.

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 20 May 2015 07:15:32 -0700

> [ Sorry, I'm on the road, and cycles are limited.  ]

Same here. :-)

> behaviour should be introduced.

Yes, agreed. Thus I think it's safest to recommend sending the service 
domain in both SRV-only, non-TLSA cases, as in the adjusted text above.

> change absent signalling via TLSA RRs.

OK, great, then I think we're in agreement.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 May 2015 12:26:52 +0000

> OK, great, then I think we're in agreement.

Yes, we are.

-- 
	Viktor.