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

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 06 February 2014 00:48 UTC

Return-Path: <viktor1dane@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 8EDDE1A0280 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 16:48:38 -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 c2YD3wStU9rN for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 16:48:36 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3805F1A0234 for <dane@ietf.org>; Wed, 5 Feb 2014 16:48:36 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4629C2AB20D; Thu, 6 Feb 2014 00:48:35 +0000 (UTC)
Date: Thu, 6 Feb 2014 00:48:35 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140206004834.GR278@mournblade.imrryr.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> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@mournblade.imrryr.org> <EC7670F0-A6C8-45FE-A2C1-7967AF9FD43B@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <EC7670F0-A6C8-45FE-A2C1-7967AF9FD43B@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
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, 06 Feb 2014 00:48:38 -0000

On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote:
> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
> 
> > Since I am relatively new here, I'll ask:  What is the distinction?
> 
> Well, that's a hard one because different people slice and dice differently. The summary I often use is:
> 
> Delivery: tell me how to use X at domain name Y
> Discovery: tell me whether there is service X at domain name Y
> 
> Another way to do this is:
> 
> Delivery: I'm pretty sure domain name Y does X: tell me what I need to know
> Discovery: I want to findo out if domain name Y does X

Hmm, ... neither of these formulations talk about future behaviour.

The SMTP draft I've been working on for most of the past year (with
Wes) is in essence doing downgrade-resistant discovery of STARTTLS
support and getting usable authentication parameters in the process.
This "discovery" is performed for each and every SMTP connection.
So it is "delivery" per my guess at a definition, but seemingly
"discovery" under yours.

So I am at a bit of a loss how the above definition of the dichotomy
bears on the question of certificate revocation.  If "discovery"
means locate once and cache indefinitely, then revocation rears
its ugly head.

Otherwise, it is just about whether some bit of policy or behaviour
is a-priori or based on DNS lookup and I don't see why revocation
support or non-support is related to "discovery" vs. "delivery".

Or is the request for CU 4 not the reason for this tangent? Are we
talking about discovery vs. delivery because of the request to
separate signing vs. encryption certs?  If so, how does the request
cross the line from "delivery" to "discovery"?

-- 
	Viktor.