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.
- Re: [dane] Agenda items for Dallas Wes Hardaker
- Re: [dane] Agenda items for Dallas Viktor Dukhovni
- Re: [dane] Agenda items for Dallas Peter Saint-Andre - &yet
- [dane] Agenda items for Dallas Olafur Gudmundsson
- Re: [dane] Agenda items for Dallas Viktor Dukhovni