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

[Paul Hoffman <[e-mail]>]

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