On 5/19/15 7:46 AM, Peter Saint-Andre - &yet wrote:
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.
OK, Matt Miller and I chatted about this over a secure IM protocol.
We're both thinking that it's best to always *indicate* the service
domain in the SNI or equivalent but *accept* both the service domain and
the target server host name during identity checking. Always indicating
the service domain minimizes code complexity and reduces the possibility
of something going horribly wrong if the client (or underlying DNS
library) thinks that SRV is secure when it really isn't.
I suggest the following text change:
OLD
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.
NEW
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
service domain is still the preferred name for TLS SNI or its
equivalent (this reduces code complexity and the possibility of
interoperability problems).
Given that this document has already been approved for publication, we
will need to check this change with Stephen Farrell, the responsible
Area Director.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
