Re: [dane] Agenda items for Dallas

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 25 January 2015 05:54 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 DA3181A3BA0 for <dane@ietfa.amsl.com>; Sat, 24 Jan 2015 21:54:02 -0800 (PST)
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 jr5gTJwPHx8Q for <dane@ietfa.amsl.com>; Sat, 24 Jan 2015 21:54:01 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD6A1A212A for <dane@ietf.org>; Sat, 24 Jan 2015 21:54:01 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3DD20282EC3; Sun, 25 Jan 2015 05:54:00 +0000 (UTC)
Date: Sun, 25 Jan 2015 05:54:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: DANE WG <dane@ietf.org>
Message-ID: <20150125055400.GJ8034@mournblade.imrryr.org>
References: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2772BE49-FDEC-4C33-AFE8-33E66B6ABBCF@ogud.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/7SiizzPsouVw46-VIouZ9WAQrx4>
Subject: Re: [dane] Agenda items for Dallas
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sun, 25 Jan 2015 05:54:03 -0000

On Sat, Jan 24, 2015 at 04:24:20PM -0500, Olafur Gudmundsson wrote:

> The chairs have requested a one hour slot 
> please send us any requests for agenda slots

Though I won't be there, I hope there will be some discussion of
any outstanding issues on the ops/6698-update draft.  In particular
if the proposal to extend "3 1 X" to apply to raw public keys is
not clear or is miguided, let's get that settled, and let's *finally*
get a LC timeframe for the document.

Speaking of LC, we seem to have lost all momentum on the SMTP and
SRV drafts, lets get those moving again please, together or
separately.

I've not yet done anything on the DANE client authentication front,
because I wanted to see the ops and SMTP drafts come to some closure
first.  This does not mean that DANE client auth is forgotten, I
think it is still a reasonable thing to specify.

Finally, I've a lot more operational experience now, and have twice
asked for feedback on the notion of adding some of the observations
to the SMTP or ops drafts, but there's been no feedback on that.

Exim 4.85 includes DANE support for SMTP, so there are now two
implementations of the SMTP draft.

In the mean-time Transip have fixed their DNS servers, and the
number of DNSSEC domains that return bogus denial of existence for
TLSA queries has dropped by ~40%.  There is distant rumbling of
progress on the forpsi front.

The S/MIME discussion seems to have stalled, perhaps someone will
have fresh ideas on how to move that forward.

Finally, it would be nice to see (correct!) DANE TLSA support in
TLS toolkits:

	OpenSSL, GnuTLS, PolarSSL, ...

while I'll likely help out on the OpenSSL front, what can be done
to get DANE support in the rest?

To get around last-mile problems, perhaps a revived effort to define
a TLS extension with "stapled TLSA records" (including the full
chain of DS/DNSKEY and RRSIG records necessary to validate them).

With stapled TLSA RRs, clients in DNSSEC-hostile environments can
elicit the relevant DNSSEC in-band data from servers.

-- 
	Viktor.