On 5/19/15 4:24 PM, Viktor Dukhovni wrote:
On Tue, May 19, 2015 at 08:07:23AM -0700, Peter Saint-Andre - &yet wrote:
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.
I disagree. What's missing here, is any dependence on the existence of
the associated TLSA records, and client support for DANE (else client
would not have checked the TLSA records).
When SRV is secure, the client proceeds to check TLSA RRs, otherwise
it does not, and reverts to non-DANE behaviour inluding any legacy
behaviour for choosing the SNI name.
When SRV is secure *AND* TLSA records are found, the client MUST
use the TLSA base domain as the SNI name, and MUST look for that
domain in the server certificate. Non-DANE servers will not have
TLSA records, so they are not affected. The client will also for
compatibility with legacy certificate deployments tolerate the
service domain as a name in the peer certificate.
See the DANE OPS draft description of the redirection use-cases.
Also compare with the SMTP draft.
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.
No. This binding along is not enough. The server needs to also publish
TLSA records to signal that support for DANE TLS (with secure redirection)
is supported by the server.
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).
I object. The fix is to delay the decision until the presence of
TLSA records has been checked.
Viktor, the text in question is from §4.1, which begins as follows:
4.1. SRV Records Only
If the client received zero usable TLSA certificate associations...
The whole point of §4.1 is to address the case where we have SRV records
and no usable TLSA records. Naturally, the client can't know that it has
no usable TLSA records "until the presence of TLSA records has been
checked" as you say. I'd agree with you if we were proposing to change
text in §4.2, but we're not, so I don't see the force of your objection.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
