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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 October 2014 23:32 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768D91A802B for <dane@ietfa.amsl.com>; Mon, 27 Oct 2014 16:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ21vcdL4PUb for <dane@ietfa.amsl.com>; Mon, 27 Oct 2014 16:32:26 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DAC81A7035 for <dane@ietf.org>; Mon, 27 Oct 2014 16:32:26 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0041D2AB219; Mon, 27 Oct 2014 23:32:23 +0000 (UTC)
Date: Mon, 27 Oct 2014 23:32:23 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141027233223.GL19158@mournblade.imrryr.org>
References: <20141027225310.29285.24437.idtracker@ietfa.amsl.com> <F0C0FC32-FAA7-4D07-A230-59A538754BCD@isoc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F0C0FC32-FAA7-4D07-A230-59A538754BCD@isoc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/stWdvq7m1I8ig0qZ-WHjKC4ZKE0
Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 23:32:36 -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.