On Sat, Mar 08, 2014 at 12:19:31PM -0700, Peter Saint-Andre wrote:
> >I am open to any reasonable terminology that conveys to the user that the
> >security policy is still "best effort", but when DANE is applicable we can
> >do better than unauthenticated TLS with cleartext fallback.
>
> [...]
>
> So if regular folks have any mental association for the word
> "opportunistic", it's something like "selfish and unscrupulous".
Perhaps so, but the draft is written for potential implementors
and to some extent administrators of SMTP TLS security, not so much
"regular folks". By the target audience, "opportunistic TLS" is
I think already understood in its proper context.
> IMHO, it would be better to use terms like "best effort security" or
> "optimistic security" (as in "we're hoping it's secure but we can't
> make any promises").
The situation calls for a reasonably clear term for a mode of
operation where DANE authenticated TLS is used whenever TLSA records
are published via DNSSEC, with fallback to opportunistic TLS otherwise.
The result is in a way doubly "opportunistic". Not only is DANE
employed when possible (downgrade-resistant modulo DNSSEC compromise),
but when DANE is not applicable, unauthenticated TLS is employed
when possible (passive attack resistant, but vulnerable to MITM
attacks). This said the intent is that the modifier "opportunistic"
is to be understood to apply to "DANE". For example, Postfix also
implements a "dane-only" security policy that can be used to insist
on DANE security. This latter security policy is described as
"mandatory" rather than "opportunistic".
So while I am quite open to using better terminology, nothing
obvious comes to mind. I don't think that "optimistic" is closer
to the mark. The optimist might assume there are no attackers and
always send in the clear. Doing best effort crypto to the extent
of hardening STARTTLS against MITM attacks is, if anything, a
somewhat pessimist/realist view of the security of the Internet.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
