Re: [dane] lists and Meeting plans for Buenos Aires?

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 05 February 2016 01:28 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 A5FE81B2BEB for <dane@ietfa.amsl.com>; Thu, 4 Feb 2016 17:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 2tgVkFwIt_VR for <dane@ietfa.amsl.com>; Thu, 4 Feb 2016 17:28: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 A277E1B2B9C for <dane@ietf.org>; Thu, 4 Feb 2016 17:28:01 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AA4AA284CDB; Fri, 5 Feb 2016 01:28:00 +0000 (UTC)
Date: Fri, 05 Feb 2016 01:28:00 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20160205012800.GR19242@mournblade.imrryr.org>
References: <20160204230640.69198.qmail@ary.lan> <D4E3DF75-272A-4AE2-B48E-5DAF01E5D1CA@insensate.co.uk> <alpine.OSX.2.11.1602042001180.72884@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.OSX.2.11.1602042001180.72884@ary.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/eXQ15_LEqGGq53Buzbglc7oyJyM>
Subject: Re: [dane] lists and Meeting plans for Buenos Aires?
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 05 Feb 2016 01:28:03 -0000

On Thu, Feb 04, 2016 at 08:14:49PM -0500, John R Levine wrote:

> >As for the use of keeping the ML open after the WG has died: remind me again how successful that has been in the IETF.
> 
> It varies.  Of the ones I can think of, the ietf-smtp list is useful as a
> place to kick around proposed SMTP changes, such as a current discussion
> about whether a compressed data extension would be a good idea and if so how
> to do it.  There are certainly plenty that either have no traffic, or the
> messages aren't interesting.
> 
> It doesn't make any difference to me whether the dane list stays open, but
> if there is more left to say about publishing stuff in the DNS secured by
> DNSSEC, it'd be as good a place as any.

We still have client DANE auth on the charter and Shumon's draft
(I'm taking a back seat this time) is in early stages of development.
And the TLS working group might soon be looking at the DANE stapling
extension, it may useful to have some veterans here to provide
feedback to the TLS WG.

So some work still remains, even though things are quite slow just
now.

At this time most of my energy is on the deployment side, in
particular at present on getting OpenSSL 1.1.0 out the door.

It seems that Claus Assmann has started looking at the DANE support
in 1.1.0, if anyone else has started testing it and has feedback,
feel free to share.  The alpha3 release scheduled for next week
might be a good time to get your feet wet.

Note, OpenSSL 1.1.0 provides peer chain verification via application
provided TLSA records, obtaining and (DNSSEC) validating those TLSA
records is up to the application.  There are opportunities here
for more "feature-complete" libraries that provide the "missing"
glue and provide a more integrated interface that does that does
the TLSA lookup with either in-application DNSSEC validation or
AD-bit trust from a local resolver, and then uses OpenSSL to do
the DANE TLS bits.

-- 
	Viktor.