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

On 5/18/15 3:09 PM, Peter Saint-Andre - &yet wrote:
> 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 protected]>
> To: [email protected]
>
> 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. :-)

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/