> On May 11, 2016, at 1:02 AM, Aaron Zauner <[email protected]> wrote: > >> With only one MTA open-source supporting DANE at present, and only with >> relatively recent releases, and OpenSSL 1.1.0 still (for a couple more >> weeks) in beta, it is not surprising that deployment is still light. >> We can't expect deployment when supporting code is not yet widely >> available. > > That's more to the point, thanks for the data. Are your raw data-sets > public anywhere (e.g. scans.io)?
Since more than one of my sources is non-public, I think I am not at liberty to publish the raw underlying data. :-( Sorry about that. The main thrust of the survey is to find DANE-enabled domains whose records go stale, and nudge them to fix. Ditto with DNSSEC zones that drop TLSA queries or mangle denial of existence. This effort has payed off in that both sets of problems are quite rare, and would not have been otherwise. With the early adoption cycle protracted, and early enthusiasm to publish records not necessarily translating to operational discipline, it is important to artificially maintain hygiene until real incentives kick in due to broader adoption. Once more senders enable DANE outbound, receiving systems with broken records will have real incentives to fix problems quickly. However, if the early adopters were all messed up, there'd be strong disincentives for broader adoption. So I've lowered the barriers to adoption by keeping the error rates much lower than they would naturally have been at this stage. Making the data public was not a primary goal, though I have posted some aggregate summaries from time to time at [email protected], [email protected], [email protected] and this list. There are still more HOWTO documents to write, a bit of time to invest in improving the experimental support in Exim, perhaps more TLS libraries to augment beyond OpenSSL, ... This takes time, but so far so good. The German and Dutch domains are an adequate incubator. The lessons will be applied to better deployment guides for those who deploy later. It me a while to realize that a combination of "3 1 1" and "2 1 1" records provides optimal operational resilience. This allows decoupling of DNS updates from cert chain updates, provided that at any given time at least one of the issuer CA or server public keys remains unchanged. One can deploy a new server keypair with a cert signed by the same issuer without pre-publishing an updated TLSA RRset, and then update the TLSA RRset some time after. Or deploy a new cert for the same server keypair from the same issuer. This is especially well suited for Let's Encrypt, but generalizes also to use of a private issuing CA. This will be written up in more detail in the next few months, bundled with Postfix docs, and ideally also as an informational RFC on DANE best-practice. -- -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
