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/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
