Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt

[Viktor Dukhovni <[e-mail]>]

On Mon, Oct 27, 2014 at 10:55:31PM +0000, Dan York wrote:

> Since I had put in a request for agenda time at IETF 91 to
> potentially talk about if there were any lessons from DANE deployment
> that could be fed back into the standards process, I did throw
> together a quick draft...
> 
> Feedback is very definitely welcome... I'm not intending anything
> with this document other than using it as a catalyst for discussions.

I periodically data-mine domains that have deployed DANE TLSA for
SMTP and have used one of the testing sites that keeps a public
log of tested domains (users can opt-out of the public log, but
many don't).

Out of ~280 domains that have TLSA RRs, 10 or so had erroneous
records:

    * Some records did not bear any relation to either the certificate
      or the public key of anything in the server's certificate
      chain.  In some cases this was after a key rotation without
      the pre-requisite DNS updates.

    * Some domains got the usage or selector wrong.  For example,
      "2 1 1" instead of "3 1 1" or "3 0 1" instead of "3 1 1",
      with the associated data otherwise be correct.

    * Some domains have usage "1", even though this is not compatible
      with SMTP.

Less serious is that some domains publish only "3 1 2" records,
even though in 6698 only SHA2-256 is a "MUST IMPLEMENT" so presumably
SHA2-512 might not always work (likely rare in practice).

Finally, some domains have bleeding edge elliptic curve DNSKEY RRs
(P-384 which is algorithm 14 IIRC), which at least my validating
resolver does not support, so they appear unsigned.  Perhaps
insufficient guidance on BCP algorithms for DNSSEC.

I've reached out to Shumon Huque, and he updated his site to generate
"3 1 1" records by default, and added a reference to the SMTP draft
at the foot of the page.

What would be even more helpful is a site that not only tests DNSSEC
validation and checks for the presence of TLSA RRs, but also connects
to the domain's MX hosts and reports whether the TLSA RRs match
reality!  I may end up partnering with some folks to build this,
but if anyone wants to do it for us, that would be great.

A 3-4% error rate in deploying TLSA records is too high, we need
better deployment validation tools.  And more prominent guidance
to pick just either of "2 0 1" or "3 1 1" for SMTP.

I'm also considering releasing a tool that validates a server's
off-line chain file against an off-line TLSA RRset.  This would
allow folks to test before they break their server, rather than
immediately after.

-- 
	Viktor.