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

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 06 February 2014 02:00 UTC

Return-Path: <eosterweil@verisign.com>
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 D9E8A1A0137 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 18:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 hlocfXebKNgc for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 18:00:35 -0800 (PST)
Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5F1A0207 for <dane@ietf.org>; Wed, 5 Feb 2014 18:00:33 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLswIDhM4Nz2QfC4Atu//PYWb8Dearv@postini.com; Wed, 05 Feb 2014 18:00:33 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1620Wmj023860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 21:00:32 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 21:00:31 -0500
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [dane] draft-ietf-dane-smime and certificate discovery
Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgAgAAkWICAAAW+AIAADHmAgAAD44CAAAfGgIAADFOA
Date: Thu, 6 Feb 2014 02:00:31 +0000
Message-ID: <80773717-0B0C-4D1F-BEFF-7A373A88D362@verisign.com>
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> <C771D712-A2F2-4513-AB45-0A65203E32F3@vpnc.org>
In-Reply-To: <C771D712-A2F2-4513-AB45-0A65203E32F3@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <19B90540FC834F4F90045BB5B840FCC4@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 06 Feb 2014 02:00:37 -0000

On Feb 5, 2014, at 8:16 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

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

<snip>

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


<meta comment>
I am only chiming in here to illustrate that there is unneeded polarization in this thread:
</meta comment>

Indeed, the above conversation (which I truncated for those who may still be keeping an eye on this) perfectly illustrates the misalignments of my message and the subsequent messages.  I never outlined discovery this way and if that is the working definition of the word here, then a better description is needed.  Key learning: how one learns the authorized key for a service domain, would be more illustrative, imho.

Eric

PS - I hope using the term ``meta comment'' doesn't run afoul of IETF sensibilities…  too soon? ;)