-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 At least for XMPP, using the target server host name was discussed in several forums over the course of many (> 5) years; I'm having trouble finding specific threads because the discussion started so long ago. The best I can do without a lot of archeology is point you at Section 1 of [POSH] and Section 6 of [XMPP-DNA] for the rationale. Both sections resulted from much discussion on mailing lists, in physical meetings, and XMPP community gatherings. I believe Olle Johansson can point you to nearly identical discussions around SIP.
TLDR -- multi-tenant hosting providers (outside of HTTPS providers) can't get a "good" cert for the service name, but can for their target server host name. Instead of forcing users to understand an "accept anyway" box that their brains are being wired to ignore anyway, we try to prove the delegation and let the hosting provider use a cert they can actually get. - -- - - m&m Matt Miller < [email protected] > Cisco Systems, Inc. [POSH] "PKIX Obtained over Secure HTTP" < https://tools.ietf.org/html/draft-ietf-xmpp-posh > [XMPP-DNA] "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)" < https://tools.ietf.org/html/draft-ietf-xmpp-dna > On 4/2/15 10:49 AM, Viktor Dukhovni wrote: > On Thu, Apr 02, 2015 at 12:53:05PM +0100, Stephen Farrell wrote: > >> Meta-question: was this something the wg discussed or did they >> just follow your lead? > > When I joined the WG in ~Mar 15, text along these lines was > already in the Tony Finch drafts srv and smtp drafts. So I was not > a party to any WG discussion of that decision, but it is obviously > the *only* way to deal with DNSSEC redirection (be it SRV or MX). > > What I was a party to was subsequent discussion of CNAME > indirection that is captured in the "ops" draft (WGLC soon, > right!). I believe we got consensus for that. And again, if the > TLSA base domain is the expanded CNAME, then that's the primary > reference identifier (used in SNI, ...) but for mixed/legacy > environments the original name is to be also be supported. > >> The reason I'm asking is the obvious one - this could be a >> surprise - if the user agent for some protocol shows >> foo.example.com (or has that in a configuration) but via >> DNSSEC/DANE/SRV > > You can add CNAME to the list. :-) > >> we end up with a TLS session with bar.example.com and if we say >> that that is ok, then we're causing potential >> developer/deployer/user surprise, and also setting an upper bound >> for the level of TLS security that is only as good as >> domain-validated. > > DANE is stronger than DV, but makes no pretense to be EV. > >> That is a defensible position (esp for the DANE wg!) but might >> surprise some application developers etc. > > I don't think there'll be many surprises, the application will > often be the one passing the reference identifiers to the TLS > library. > > At least in OpenSSL (where I'm involved in designing the DANE > support) the TLS library is not going to be doing the TLSA > lookups. Rather the application will call use some DNSSEC library > to obtain the service specification records (see DANE vocabulary) > and find the associated TLSA RRs. It will then hand these (TLSA > base domain, RRs, and additional names to accept) off the the TLS > library as verification input parameters. > >> One other question: you mentioned SNI below. Is that very >> relevant here, given we're not talking about the web (that won't >> use SRV) and afaik most use of SNI is for the web. > > SNI is a TLS mechanism. It is not a web mechanism. Any time a > server handles multiple domains, SNI is potentially useful. We've > worked hard (in the ops draft) to make it less necessary to use > SNI, precisely by specifying that the primary reference identifier > must be the expanded name (except when CNAME expansion is not > secure). > >> So, for which non-web applications is SNI sufficiently important >> to justify this (potential) level of developer surprise? > > No surprise, on the contrary, as an SMTP developer (e.g.) I > *expect* that the reference identifer is the MX hostname, we've > been waiting for DNSSEC to make this possible for many years now. > Lots of domains have shared backup MX hosts, which can't possibly > have certificates for all the domains, but can field a certificate > for their own name. > > Better yet, with DANE-EE(3) the name and expiration of the > certificate are entirely irrelevant, making multi-tenancy even > easier. > > [ With DANE-EE(3) Postfix will happily accept certificates in which > the Subject DN and Issuer DN are empty RDN sequences, there are no > subject alternative names (it's just a fancy key container), and > the expiration time precedes the inception time, but I've been > asked to not speak of such PKIX-violating apostasy, and I've been > good about that. :-) I'll just make a retroactive exception for > April 1 below. ] > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVHayNAAoJEDWi+S0W7cO1ASwH/jIvcfffPWVgA55/rfv4fI5H 7AC7M3gwGiRD2nejgz6pB+SgD9NAC4oCGmnmf3Bm9/9gqHEY0Jy50rnsGokzUc3q srGV7KcE80yuQLTJ6Azv1bilosyfK1w8gWDNpoxhfv2JtaVtslhOcfv8aLFosTfj T5Ag5JvDtoN47cPFQ6v8LxHYnGZRG4P9cDgnrbHqEDkS/O4F+kV8z+n3Xq3c2JQc cj6ZwSgw/vad92JxscZ6tHpGJnzW8fDyZH9rpclx9gGYnUIb3BzKsYEfnPZPORR7 aHedgTZNW3wHv6tQyTcze9e85PTArCLY+rZWMTIF17dew+kHZEsAG9MYgjLSlZI= =lv5P -----END PGP SIGNATURE----- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
