Re: [dane] draft-ietf-dane-smime and certificate discovery

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 05 February 2014 23:29 UTC

Return-Path: <paul.hoffman@vpnc.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 663C41A02D1 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 15:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 l9HUZLh4fYfq for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 15:29:33 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EAF291A02C7 for <dane@ietf.org>; Wed, 5 Feb 2014 15:29:32 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s15N9SJ9039411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Feb 2014 16:09:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <FAB9D9AB-023B-48E3-BD26-15FC9B87FE3F@verisign.com>
Date: Wed, 5 Feb 2014 15:29:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <A1C41700-578C-45C1-9A66-ACC051970F47@gmail.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <FAB9D9AB-023B-48E3-BD26-15FC9B87FE3F@verisign.com>
To: Eric Osterweil <eosterweil@verisign.com>
X-Mailer: Apple Mail (2.1827)
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
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: Wed, 05 Feb 2014 23:29:34 -0000

On Feb 5, 2014, at 1:19 PM, Osterweil, Eric <eosterweil@verisign.com> wrote:

> Thanks for the quick response.  I am, however, a little puzzled by it.  So, is there some reason why these discussions here (on the WG list) are not the actual substance of determining what the DANE WG wants?  As I understand it (perhaps incorrectly?), we are discussing a working group document, so discussion of its contents should be inbounds and any resulting rough WG consensus should help direct its contents, no?

It is often better if a WG decides on a direction, not just a specific technology. During the TLSA discussions, there were many threads about delivery vs. discovery, and the WG early on went for "delivery, not discovery". As I said in the previous message, if the WG wants to revisit that decision and goes towards "discovery", there are lots of ways we can make TLSA and SMIMEA records have some interesting new properties.

> As for the broader statement of what DNS is for, and what the IETF at large thinks, I think perhaps you have expressed your own opinion here, and I (personally) do not agree.  In my view, DNS is (very much) a resource mapping (i.e. learning) mechanism.  That's how we find routable endpoints for HTTP. ;)  Content delivery aside.  I suspect you and I may actually be on the same page on that one, but apparently not on the learning issue.

I'm agnostic, and am happy for this document and TLSA go whichever way the IETF wants. However, I'm not in favor of trying to cross the line and see if the IETF notices.

> Back to the main issue, I am following up on Scott's solicitation for discussion about his proposed changes, and expressing my support for them.  I have read your response to those and responded to it, and I am happy to discuss the technical details further.

It's not the technical issues that are important, however.

So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic people want to revisit?

--Paul Hoffman