> On Jan 14, 2016, at 11:01 AM, Viktor Dukhovni <[email protected]> wrote: > > On Thu, Jan 14, 2016 at 03:10:34PM +0000, Osterweil, Eric wrote: > >>>> DANE Summary >>>> 16065 DANE enabled zones with TLSA records >>>> >>>> 65 PKIX based Trust Anchor TLSA records (Cert Usage 0) >>>> 541 PKIX based End Entity TLSA records (Cert Usage 1) >>>> 266 DANE based Trust Anchor TLSA records (Cert Usage 2) >>>> 5791 DANE based End Entity TLSA records (Cert Usage 3) >>> >>> 6663 > > Ok, so that's 6663 TLSA RRsets, but a much larger number of protected > zones due to MX indirection. So I would clearly separate the RRset > count from the "protected domain" count.
Yep. The RR counts are listed below the zone count. I think this is precisely what led you to notice. That is, all of the counts below the zone count are RR counts. > >>> 1996 Zones have deployed TLSA for SMTP (Port 25) > > So the missing ~10k "zones" (protected domains) are here, because > the other ports are rarely (RFC6186 notwithstanding) subject to > indirection. Any of the mail protocols is subject to this indirection, as those DANE records are based off the MX record. > That is you've found 1996 MX hosts with TLSA RRsets? Or 1996 zones > with 1 or more MX hosts with TLSA RRsets, or a total of 1996 TLSA > records for port 25? I am guessing the latter, because that's what > makes the "certificate usage" total equal to the "by port" total. There are 1996 TLSA Resource Records that have the domain name _25._tcp.<domain name>. Each RR at every domain name gets counted separately. So, if someone has two RRs at the same domain name, SecSpider counts two, not one. > In that case our numbers are similar, I have 10.7k email SMTP > domains covered by TLSA records of 1564 MX hosts with 2212 TLSA > RRs (at least, because there are cases where I don't look for any > TLSA RRs on worse priority MX hosts if a better priority MX hosts > have no TLSA records). Of the 10.7k domains 200 have incomplete > TLSA record coverage in that some MX hosts are not protected, so > the "domain" is not secured against MITM by attackers who block > access to the protected MX hosts. That’s very interesting! Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
