On Feb 5, 2014, at 8:16 PM, Paul Hoffman <[email protected]> wrote:
> On Feb 5, 2014, at 4:48 PM, Viktor Dukhovni <[email protected]> wrote: > >> On Wed, Feb 05, 2014 at 04:34:41PM -0800, Paul Hoffman wrote: >>> On Feb 5, 2014, at 3:50 PM, Viktor Dukhovni <[email protected]> >>> 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? ;) _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
