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

From: Dan York <[email-masked]>
Date: Mon, 27 Oct 2014 22:55:31 +0000

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.

Dan

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-york-dane-deployment-observations-00.txt
Date: October 27, 2014 6:53:10 PM EDT
To: Dan York <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-york-dane-deployment-observations-00.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dane-deployment-observations
Revision: 00
Title: DANE Deployment Observations
Document date: 2014-10-27
Group: Individual Submission
Pages: 4
URL:            http://www.ietf.org/internet-drafts/draft-york-dane-deployment-observations-00.txt
Status:         https://datatracker.ietf.org/doc/draft-york-dane-deployment-observations/
Htmlized:       http://tools.ietf.org/html/draft-york-dane-deployment-observations-00

Abstract:
  This document provides some observations about the deployment of the
  DANE protocol to date and some questions for discussion on the DANE
  mailing list and potentially at the IETF 91 meeting of the DANE
  Working Group.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Oct 2014 23:32:23 +0000

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.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 29 Oct 2014 17:18:38 +0100

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.

IMO lack of really secure DNSSEC support is *the* major blocker. So I disagree
with your comment at the end of section 2.

And I have some personal security concerns about the DNSSEC auto-signing many
sites seem to implement and the security of registry (web) interfaces. I'm
pretty sure attackers will go that route just like they attacked registry
(web) interfaces of X.509-based PKI implementations.

Also I don't like inventing a bunch of DNS RR types for different purposes.

Ciao, Michael.