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

"Osterweil, Eric" <> Thu, 06 February 2014 02:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D9E8A1A0137 for <>; Wed, 5 Feb 2014 18:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hlocfXebKNgc for <>; Wed, 5 Feb 2014 18:00:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 92F5F1A0207 for <>; Wed, 5 Feb 2014 18:00:33 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUvLswIDhM4Nz2QfC4Atu//; Wed, 05 Feb 2014 18:00:33 PST
Received: from ( []) by (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 ([::1]) by ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 21:00:31 -0500
From: "Osterweil, Eric" <>
To: Paul Hoffman <>
Thread-Topic: [dane] draft-ietf-dane-smime and certificate discovery
Date: Thu, 6 Feb 2014 02:00:31 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Feb 2014 02:00:37 -0000

On Feb 5, 2014, at 8:16 PM, Paul Hoffman <> wrote:

> On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni <> wrote:
>> On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote:
>>> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni <> wrote:


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


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