Re: [dane] Need better opportunistic terminology

Viktor Dukhovni <viktor1dane@dukhovni.org> Sun, 09 March 2014 19:55 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB41A0375; Sun, 9 Mar 2014 12:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYgnB2PcZO8t; Sun, 9 Mar 2014 12:55:18 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BEEAB1A037E; Sun, 9 Mar 2014 12:55:18 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CD942AB250; Sun, 9 Mar 2014 19:55:12 +0000 (UTC)
Date: Sun, 9 Mar 2014 19:55:12 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <20140309195512.GQ21390@mournblade.imrryr.org>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com> <20140307004432.GH21390@mournblade.imrryr.org> <531B6D43.7030806@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <531B6D43.7030806@stpeter.im>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JmfkknsCISOjU18EpvBCceuT7LE
Cc: saag@ietf.org, dane@ietf.org
Subject: Re: [dane] Need better opportunistic terminology
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 19:55:20 -0000

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.