Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 15 February 2014 02:13 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 5E33B1A02EE for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 18:13:37 -0800 (PST)
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 i0t1rOxEG2H4 for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 18:13:35 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 229D61A02E0 for <dane@ietf.org>; Fri, 14 Feb 2014 18:13:34 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5472A2AB22D; Sat, 15 Feb 2014 02:13:32 +0000 (UTC)
Date: Sat, 15 Feb 2014 02:13:32 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140215021332.GM278@mournblade.imrryr.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O0_EQDIGkN5M2ijxRW_3jrHNdB4
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Sat, 15 Feb 2014 02:13:37 -0000

On Fri, Feb 14, 2014 at 04:48:32PM -0800, Paul Hoffman wrote:

> Personally, I don't care about MITM protection if it comes at
> the cost of getting more organizations to turn on opportunistic
> crypto.

One quick comment, there is no conflict between opportunistic DANE
TLS and "pre-DANE" opportunistic TLS.  So I would take issue with
"at the cost of".  If anything the two are symbiotic.

The first step for an SMTP server operator towards greater channel
security is to enable STARTTLS if they have not already done that.
At that point all TLS-enabled clients (be they DANE aware or not)
will generally send email over unauthenticated TLS.

Once the server operator determines that TLS is working satisfactorily
for all clients (observed over weeks to months) he may decide to
enable DNSSEC for his domain and if that works out OK, later publish
a TLSA "3 1 1" RRset that matches his server certificate.  The
certificate will not capriciously expire causing an SMTP outage,
it will only become invalid through explicit removal from the TLSA
RRset (presumably after it is augmented by an RR matching a new
certificate which then replaces the original).

This simplified authentication protocol for SMTP is carefully
designed to avoid most operational pitfalls, and the hope is that
it will be reliable enough to be enabled by default on clients and
stable when deployed with care on servers.

All that aside, the main point is that there is NO conflict between
"pre-DANE" opportunistic TLS and DANE opportunistic TLS.  The latter
is turned on only at the request of the server operator.

As to why MTA to MTA SMTP is more special in this regard than HTTPS,
the main reason is that MTAs don't generally roam into hotels,
internet cafes, and other DNSSEC hostile environments.  Being server
infrastructure MTAs are much less likely to run into MITM false
positives due to shifting network conditions.

-- 
	Viktor.