Re: [dane] Need better opportunistic terminology

Viktor Dukhovni <> Fri, 07 March 2014 10:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E4DF51A0159; Fri, 7 Mar 2014 02:20:35 -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 5PFCN6K_gDyQ; Fri, 7 Mar 2014 02:20:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C00571A012B; Fri, 7 Mar 2014 02:20:32 -0800 (PST)
Received: by (Postfix, from userid 1034) id 3E8D12AB24B; Fri, 7 Mar 2014 10:20:27 +0000 (UTC)
Date: Fri, 7 Mar 2014 10:20:27 +0000
From: Viktor Dukhovni <>
To: Michael Richardson <>
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 10:20:36 -0000

On Fri, Mar 07, 2014 at 04:35:06AM -0500, Michael Richardson wrote:

>     > 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).
> And, in particular, I think that "opportunistics TLS" interoperates with
> "opportunistics DANE TLS".  The two sides don't have to have to known each
> other's policies.

Yes.  This is quite common.  Servers generally don't know how and
whether clients perform TLS authentication.  The best they can hope
for is that clients find their certificates useful.  I should
however note that opportunistic DANE TLS sends SNI when the server
has TLSA records.  We don't yet know whether there are MTA
implementations which would fail to complete the TLS handshake when
they don't have a certificate with an exactly matching name.  The
draft requires servers to continue with a suitable default certificate
if no SNI match is found.

Since the draft precedes any significant deployment of SMTP servers
with TLSA records, one can hope that server operators will not
publish TLSA records if their server is "allergic" to "opportunistic"
DANE TLSA clients (really SNI hints that turn out to not match any
certificate configured on the server).  Thus far no such servers
have been observed, but the number of deployed clients and servers
is still quite small.

I am not aware of any MTAs that support server-side SNI, but this
could be mere ignorance.  If some do, those might be the ones that
get unhappy with unexpected SNI signals from clients.  Servers that
have completely ignored SNI to date (e.g. Postfix) will continue to
do so.

Any suggestions for a better name for this mode of operation?