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

["Osterweil, Eric" <[e-mail]>]

On Feb 5, 2014, at 8:16 PM, Paul Hoffman <[e-mail]> wrote:

> On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
>> On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote:
>>> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni <[e-mail]> 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? ;)