Re: [dane] [saag] Need better opportunistic terminology

Viktor Dukhovni <> Thu, 13 March 2014 00:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B1541A07C6; Wed, 12 Mar 2014 17:38:02 -0700 (PDT)
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 FwiQ3XW3pyFr; Wed, 12 Mar 2014 17:37:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C69511A07A6; Wed, 12 Mar 2014 17:37:58 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 470C92AADF5; Thu, 13 Mar 2014 00:37:52 +0000 (UTC)
Date: Thu, 13 Mar 2014 00:37:52 +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] [saag] 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: Thu, 13 Mar 2014 00:38:02 -0000

On Wed, Mar 12, 2014 at 02:59:34PM -0700, Joe Touch wrote:

[ It seems the discussion has moved on beyond the specifics of the title of
  the SMTP with DANE draft: "SMTP security via opportunistic DANE TLS".  So
  if anyone has a considered proposal for a better name, please start a new
  thread on the DANE list only, or just send me your suggestions off-list. ]

> No disagreement; there seems to be a need then for two terms:
> 	1. unauthenticated key exchange/use
> 	2. security that uses authentication when available,
> 	but allows unauthenticated methods as a backup

Moving beyond the SMTP with DANE use-case, the space for SMTP alone
is definitely larger than just two cases.  For example, with email,
we have:

    0. Opportunistic TLS.

	What's opportunistic here is not the key management (long-term
	keys are not used or ignored), but the *use* of TLS.  If
	the server EHLO response includes STARTTLS, TLS is attempted,
	otherwise not.

    1. Mandatory unauthenticated TLS (similar to 1. above).

       Use of TLS is not opportunistic, the transmission channel
       is always encrypted.  However as with "0." there is no

    2. Opportunistic use of authenticated TLS (e.g. via DANE) with
       fallback to "0." when the destination authentication policy
       is not available.
	(with the "dane" security level)

       Here when "usable" secure TLSA records are published,
       the server is always authenticated.  But otherwise, we
       do our best to at least not send in the clear.

    3. Mandatory authentication:
	(with the "dane-only" security level)

       Similar to HTTPS, but no user to click OK, so deployment is limited
       to small set of administrator designated destinations.

    4. Audit-only authentication (on the drawing board for Postfix):

       An attempt is made to authenticate the peer with the
       administrator selected policy (2 when destination policy is
       known or one of static policies in 3).  Authentication
       results are logged, but mail delivery proceeds even when
       authentication fails.  The failure mode can be configured
       to either "0." or "1."

There are of course additional models (TOFU, Tack, ...)

So perhaps a small list of terms (nouns or noun-phrases) will not
cover all the models in a generic way.  We can however provide some
guidance on the appropriate use of some popular "adjectives", to
encourage people to use them in a more appropriate, consistent

My contention is, for example, that the use of "opportunistic" in
"opportunistic TLS" to describe TLS in case "0" is a proper use of
that adjective.  Similarly "opportunistic DANE TLS" for case "2"
is also reasonable.  By way of contrast one might speak of "mandatory
TLS", "mandatory DANE TLS", ...

Finally, the terminology is the least of our worries, lets get more
of the security protocols deployed!