Re: [dane] Meeting in Hawaii?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 02 October 2014 23:30 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 9FE281ACF9C for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 16:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] 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 DuFeIQRxTbZi for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 16:30:19 -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 9B3F91A8823 for <dane@ietf.org>; Thu, 2 Oct 2014 16:30:19 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DFF6C2AB2A7; Thu, 2 Oct 2014 23:30:17 +0000 (UTC)
Date: Thu, 02 Oct 2014 23:30:17 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141002233017.GQ13254@mournblade.imrryr.org>
References: <CAHw9_iLV1uWX2Fg5H9dBaMr=DsrGmyB_BJteP-kBA0MnXCkJ2w@mail.gmail.com> <E36D8CE6-F5E8-4606-950D-430FEAEA3523@kirei.se> <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4C36FDC5-12D2-48C1-A3D5-7AA4090E98C8@isoc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tzQlsSO2rhOwLVYTbpPZCeyJRYs
Subject: Re: [dane] Meeting in Hawaii?
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: Thu, 02 Oct 2014 23:30:22 -0000

On Wed, Oct 01, 2014 at 11:49:48AM +0000, Dan York wrote:

> All the authors of the various drafts on DANE for email (S/MIME
> and OpenPGP) will be there, and we will have discussions on the
> list beforehand. Given this, I for one, hope we can meet and flesh
> out any details left on this topic.

FWIW, I will not be present.

> To Jakob's point, we're going to have a significant number of
> the DANE-related authors and implementors all together at IETF and
> I think a general topic of "What Else Do We Need To Do For DANE
> For Email" could be a good discussion topic.

I am at Frankfurt Airport after a trip to speak about DANE at the
DENIC registrar technical conference.

You may be aware that the most substantial DANE deployments are
for now in Germany, and this is likely to continue through the rest
of 2014, with additional .de deployments, with little progress
elsewhere.

[
  Many SMTP domains with TLSA RRs are listed at:

      https://www.tlsa.info/statistics/best_results

  though this site may not actually be checking that
  the servers actually have a matching certificate chain,
  rather it looks like it just checks for the presence of
  DNSSEC validated TLSA RRs.  Ironically, the site's HTTPS
  server has an expired stapled OCSP response at the moment.
]

It seems that DNSSEC deployment *is* by far the main obstacle.
Registrars need to support DS RRs and ideally be able to host DNSSEC
domains.  Unlike registries looking after one or a handful of
domains, registrars host thousands to millions of domains.  One of
the issues raised at the DENIC meeting, is that DNSSEC-capable
nameserver software that scales well to very large zone counts is
by no means abundant.  Reportedly only PowerDNS comes close, and
at least some registrars are reluctant to put all the eggs in one
basket and rely on just a single software platform.

So if there is anything that can be done to spur deployment of
additional scalable nameservers, that would be great.

Of course there is also impedance at the consumer end, with a lot
of cable-modems and the like acting as DHCP server + DNS proxy,
but not supporting DNSSEC.

Once DNSSEC is working, the actual DANE deployment is rather a lot
simpler.  Just publish some TLSA RRs and implement the right
key-rotation strategy.

For now, only Postfix implements DANE outbound (inbound any MTA
will do, all the DANE-specific code is on the client).  Adoption
beyond .de would be greatly advanced if at least one large email
provider published TLSA RRs and/or implemented DANE outbound.

Gmail, Microsoft Office365, Yahoo, AOL, should at least seriously
consider plans towards SMTP with opportunistic DANE TLS.  If you can
do anything to prod the right people, that would be great.

Beyond SMTP, it would be great to get some early design work underway
for opportunistic DANE TLS with "h2" (HTTP).  I don't see DANE
adoption for HTTPS any time soon (at least not until EV certs go
out of style).  DANE can however substantially harden opportunistic
security with HTTP, provided last-mile is under control.

This runs into the "last-mile" problem for DNSSEC.  Where are we
with that?

I explained to the DENIC registrars how DANE simplifies virtual
hosting, obviates CRLs and improves effectiveness of "revocation"
(de-publishing bad data from DNS).  These are good features for HTTP
to have, but we seem to be no closer to DANE for HTTP.

In the pipeline we have just Exim, some XMPP software, and more
German domains.

> - are there places where it would be helpful if there were
> reference implementations of DANE support?  For example, DANE for
> email got a boost when Viktor added it to Postfix.  Are there other
> commonly-used open source projects where the addition of DANE
> support would help move deployment along?

Well, Sendmail support would also be nice.  But more importantly
some of the closed MTAs would probably be more important:

    * Microsoft Exchange
    * Ironport, Barracuda and similar appliances
    * Gmail, Yahoo, AOL, Office365, ...

Of course having reasonably feature-complete support for DANE in
TLS toolkits would really help.  This is why I've joined the OpenSSL
team, with a mission to work on integrated DANE support, once some
of the more urgent priorities in OpenSSL are resolved.

It would be helpful to have sound DANE support in NSS, GnuTLS,
PolarSSL, ...  provided these were designed and implemented with
care and are not just incomplete prototypes.  In particular, I
don't have the cycles to design-review/code-review all DANE
implementations, but such reviews are likely necessary.  Yes,
testing can find many classes of bugs, and a DANE test-suite would
be useful.

-- 
	Viktor.