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

[Peter Saint-Andre - &yet <[e-mail]>]

On 5/19/15 4:45 AM, Kim Alvefur wrote:
> On 2015-05-19 00:03, Peter Saint-Andre - &yet wrote:
>> 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.
>
> 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.

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.

>> 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.
>
> Right, dane-srv doesn't have authority over XMPP specifics.
>
> Thanks :)

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/