On Tue, Aug 05, 2014 at 07:58:51PM -0700, Dave Crocker wrote:
> On 8/5/2014 7:55 PM, Viktor Dukhovni wrote:
> > We'll have to disagree on this. From the perspective of an MTA
> > delivering mail to all possible domains, its security policy is
> > opportunistic, doing the best it can with each destination. When
> > DANE support is enabled, it becomes possible to authenticate some
> > peers, this is still opportunistic security, with the bar set to
> > the right level for each peer, and mail delivery in cleartext should
> > a previously DANE-enabled domain withdraw its TLSA RRs, ...
>
> I've read the above several times but do not really understand what it
> means.
DANE with authentication can be either opportunistic (enabled via
discovery on a peer by peer basis) or mandatory (required by local
policy, URI scheme, ...). Postfix for example supports both
opportunistic and mandatory DANE TLS:
http://www.postfix.org/TLS_README.html#client_tls_dane
> Also the issue is not whether we agree but what the technical details
> are that qualify this as "opportunistic" rather than authenticated
> encryption that happens to use DNSSec as a form of CA.
The term "opportunistic security" is new, and can be defined, within
reason, as we see fit. The proposed definition includes authentication
that is based on published peer capabilities (discovered authentication
support) under the umbrella term of opportunistic security, and rightly so.
> For a term to be useful, there must be a clear and consistent way of
> applying it.
Opportunistic peers are willing to set the bar at various levels
depending on peer capabilities. They don't operate at a single
fixed (all or nothing) security policy. Publication of TLSA RRs
(for example) is one way of signalling a higher bar for a particular
peer, STARTTLS is another (though not as high, and not immune to
active attack).
> The exchange we are having right now makes the meaning -- and therefore
> utility -- of opportunistic (foo) -- questionable. It is simply not
> useful to have such a basic assessment reduce to "we'll have to disagree"...
Perhaps I said that wrong, I did not mean to shut down the
conversation, however, I am more than willing to clarify my stance
on a definition that ranges from cleartext to authenticated encrypted
comms that resist both passive and active attacks. I think we are
well past the point where I need to consider substantively narrower
definitions. We can certainly debate the clarity and wording of
the text.
--
Viktor.