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

On 5/18/15 3:24 PM, Peter Saint-Andre - &yet wrote:
> 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. :)

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/