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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 06 February 2014 01:16 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 D41891A02E5 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 17:16:29 -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 SyfLACPT1PJS for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 17:16:28 -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 AAB581A01BC for <dane@ietf.org>; Wed, 5 Feb 2014 17:16:28 -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 s160uNwp042425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Wed, 5 Feb 2014 17:56:25 -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: <20140206004834.GR278@mournblade.imrryr.org>
Date: Wed, 5 Feb 2014 17:16:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C771D712-A2F2-4513-AB45-0A65203E32F3@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> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org> <20140205235002.GP278@mournblade.imrryr.org> <EC7670F0-A6C8-45FE-A2C1-7967AF9FD43B@vpnc.org> <20140206004834.GR278@mournblade.imrryr.org>
To: "<dane@ietf.org>" <dane@ietf.org>
X-Mailer: Apple Mail (2.1827)
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: Thu, 06 Feb 2014 01:16:30 -0000

On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> 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.

I bet others will say the same. However, I looked at it as "I believe that SMTP server at domain name Y does TLS, give me its certificate". This is the same as "I believe that HTTP server at domain name Y does TLS, give me its certificate".

This is quite different than using the DNS to determine if domain name Y does SMTP/TLS or HTTP/TLS. That's why there are no semantics associated with the TLSA records that say "if DANE says there is a TLS server and you can't reach it, there is something wrong".

(And, yes, my TRYTLS record proposal definitely slides right into the discovery zone. And that's why it has gotten roundly ignored.)

--Paul Hoffman