>>>>> "JW" == Jonas Wielicki <jo...@wielicki.name> writes:
JW> On 08.11.2015 17:45, James Cloos wrote: >> When TLSA records are used, the SRV destination should be the only nam JW> e >> checked for in the certs. JW> Is that so? At least with DANE-EE, no checks on the host name need to be JW> done anymore. (It is used to lookup the TLSA records though, which could JW> be what you meant to say.) Yes, I left that part unsaid. So if the cert needs to be checked for a name, then only the machine name need be checked. >> It would be best for xmpp to target that model for all TLS usage. >> It is much easier than the pre-tlsa options are. JW> In principle, I agree. However, DANE support, especially in clients, is JW> not yet widespread enough to rely on that. The barriers to implement JW> DANE are also much higher than those of implementing the ProtoXEP under JW> discussion would be, at least until DANE support lands in the popular JW> TLS stacks. How about recommend that all clients and servers when connecting to a(nother) server try dane first, including expecting the remote's hostname in the cert (if anything), and only fall back to the pre-dane style (where the userid's domainname should be in the cert) if dnssec a/o tlsa were unavailable. JW> Also, DNSSEC is still not deployed in all top level domains, I think JW> the (for XMPP) very relevant .im for example is still lacking it. Unfortunate! JW> If we could rely on DANE everywhere, SNI would not be needed at all JW> anymore; a service could just present a single certificate for all XMPP JW> domains and publish the corresponding TLSAs in the zone. Exactly; that is the long term solution. Hacking around the current lack of universal dnssec support will need to be done in the short term, but the goal should be signed rrs for everything and tlsa for associating certs with dns names. The description which was posted here as a goal is good, but should also reference rfc 7673 and use that when it is available. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6