Re: [dane] Need better opportunistic terminology

Viktor Dukhovni <> Fri, 07 March 2014 00:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28C2A1A014E; Thu, 6 Mar 2014 16:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tevUjjtw6wRg; Thu, 6 Mar 2014 16:44:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2B4F71A00CA; Thu, 6 Mar 2014 16:44:38 -0800 (PST)
Received: by (Postfix, from userid 1034) id 954212AB24D; Fri, 7 Mar 2014 00:44:32 +0000 (UTC)
Date: Fri, 7 Mar 2014 00:44:32 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Need better opportunistic terminology
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Mar 2014 00:44:41 -0000

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.


    In the Postfix community, we've historically used the term
    "opportunistic TLS":

    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.

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

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

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

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.