>>>>> "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

Reply via email to