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

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

This thread started on the DANE WG list but I think it belongs here.

-------- Forwarded Message --------
Subject: Re: [dane] DANE-SRV, SNI functional equivalent and XMPP
Date: Mon, 18 May 2015 15:03:54 -0700
From: Peter Saint-Andre - &yet <[email-masked]>
To: [email-masked]

On 5/17/15 9:55 AM, Kim Alvefur wrote:
> Hello list!

Hi Zash!

> 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

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/

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

---

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

> DANE WG list. I'll forward this message to that list and continue the

So, draft-ietf-xmpp-dna (§5.1) says:

    The DANE prooftype makes use of the DNS-Based Authentication of Named
    Entities [RFC6698], specifically the use of DANE with DNS SRV records
    [I-D.ietf-dane-srv].  For XMPP purposes, the following rules apply:

    o  If there is no SRV resource record, pursue the fallback methods
       described in [RFC6120].

    o  Use the 'to' address of the initial stream header to determine the
       domain name of the TLS client's reference identifier (since use of
       the Server Name Indication extension (TLS SNI) [RFC6066] is purely
       discretionary in XMPP, as mentioned in [RFC6120]).

As I understand it, Kim is saying that if a client were to (i) discover 
via SRV methods that the service domain "example.com" is located at the 
target server "hosting.example.net" and (ii) discover via DANE methods 
that the expected identity of the certificate for the connection 
endpoint is not the service domain but the target server host name, then 
(iii) it would break things on the XMPP network for the client to 
specify a 'to' address of the target server host name instead of the 
service domain because (iv) the XMPP server software figures out which 
certificate to present based on the service domain, not the target 
server host name.

I'm not sure about that. It seems to me that if an application service 
provider is doing the whole DANE thing, then it will always just present 
a certificate for "hosting.example.net" instead of for "example.com" or 
any particular service domain hosted there, so why does it even need to 
differentiate?

Now, there might be some other reason to want the 'to' address to be the 
service domain (e.g., maybe some cluster or machine is dedicated for 
hosting that service domain, or the application service provider wants 
to terminate spurious connections as quickly as possible and not use 
TLS/SASL resources and round trips for accounts that it doesn't host), 
but I'm not yet convinced that choosing the right certificate is the reason.

However, I freely admit that I might be missing something, so 
enlightenment would be appreciated. :)

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 May 2015 23:26:01 +0100

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

Actually, it's a interesting problem. As I understand it, SNI is
unencrypted in the handshake, so offers no value, but could easily cause
major confusion if used, since it is not clear which might take precedence.

However, my understanding - possibly flawed - is that TLS version 1.3
introduces encrypted handshakes, and then it might be useful to hide the
server domains used.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 18 May 2015 16:32:45 -0700

On 5/18/15 3:26 PM, Dave Cridland wrote:
>
> On 18 May 2015 23:09, "Peter Saint-Andre - &yet" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > From: Peter Saint-Andre - &yet <[email-masked]
> <mailto:[email-masked]>>
>  > To: [email-masked] <mailto:[email-masked]>
>  >
>  >> to='xmpp23.hosting.example.net <http://xmpp23.hosting.example.net>'
> in the stream header, as that is the

Good point.

> introduces encrypted handshakes, and then it might be useful to hide the

I admit that I haven't been tracking the TLS 1.3 initiative, although I 
recall that being one of the goals. However, since TLS 1.3 isn't here 
yet, it doesn't help us with draft-ietf-xmpp-dna (although we might want 
to mention that this applies to TLS 1.2 and lower).

Peter

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

---

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

> enlightenment would be appreciated. :)

See further discussion on the DANE list:

http://www.ietf.org/mail-archive/web/dane/current/msg07686.html

I think draft-ietf-xmpp-dna is fine (it just says "use the 'to' address, 
not SNI") whereas draft-ietf-dane-srv is the document that needs to be 
adjusted slightly.

Peter

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