On Thu, Mar 06, 2014 at 09:23:23AM +0000, Phillip Hallam-Baker wrote:
> The term opportunistic has become the new synonym for 'Good' but it is
> being used for many different things.
Since I am the primary perpetrator of the thought crime in question, :-)
I'd like to explain the term we used, and why, and solicit a better
term if the IETF has a better way of expressing the underlying idea.
Background:
In the Postfix community, we've historically used the term
"opportunistic TLS":
http://www.postfix.org/TLS_README.html#client_tls_may
to refer to a client that employs TLS encryption without any
authentication when the server's EHLO response includes STARTTLS.
In this case the client is willing to otherwise send in the clear,
and, in fact, will fallback to cleartext when the TLS handshake fails.
In the (new) DANE SMTP draft the terminology section reserves the
term "(pre-DANE) opportunistic TLS" for the above client behaviour.
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-07#section-1.1
We introduce a new term (also listed in the terminology section) which is
"opportunistic DANE TLS".
The thought crime in question predates the last summer's pervasive
monitoring disclosures. The work on the draft began in March 2013,
and the new term was used (correctly or otherwise) from the outset.
So you might ask what was the word "opportunistic" doing in our
avant-garde use of the term "opportunistic DANE TLS"? The answer
is that as with (pre-DANE) opportunistic TLS, the client is willing
to send in the clear to any server for which no "secure" TLSA
records are available.
Thus, until the happy future when a significant fraction of domains
are DNSSEC signed, and their MX hosts are accompanied by DNSSEC-validated
"secure" TLSA records, in practice the protocol is essentially the
same as with (pre-DANE) opportunistic TLS. The client employs the
best security level available (including cleartext).
What DANE does is raise the bar, so that for some destinations,
the ones with secure TLSA records, the best available is authenticated
TLS, and this status can be determined in a downgrade-resistant
manner.
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 Phillip is quite right that DANE gets us stronger semantics,
but I would argue, that because the actual security posture is
*conditional* on published receiving system capabilities, from the
perspective of the sending system, this is just a "hardened" version
of opportunistic TLS where, for just some destinations not known
to the sender in advance, MITM attacks cannot trivially downgrade
senders to plaintext or compromise transport integrity or
confidentiality.
So in Postfix documentation, we'll still describe the resulting
security as a form of opportunistic TLS (this is how the email
administrator should think about this "hardened" best-effort
security).
http://www.postfix.org/TLS_README.html#client_tls_dane
In IETF documents, I'm open to anything that aligns reasonably well
with other documents. We do not mean to cause any confusion. If
there is a clear precedent or consensus for naming "opportunistic
DANE TLS" in some other way, I for one have no objections.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
