[dane] Lukewarm discussion: DANE for opportunistic TLS protocols

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 14 February 2014 20:00 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 217461A0361 for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 12:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jFGCf6flNUtc for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 12:00:05 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org []) by ietfa.amsl.com (Postfix) with ESMTP id 45FC21A0323 for <dane@ietf.org>; Fri, 14 Feb 2014 12:00:04 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BB35D2AAD11; Fri, 14 Feb 2014 20:00:02 +0000 (UTC)
Date: Fri, 14 Feb 2014 20:00:02 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140214200002.GK278@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/d1ICZx_epgppr72Udfxv47DT6vA
Subject: [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: Fri, 14 Feb 2014 20:00:08 -0000

Paul Hoffman (thanks) points out that there may be prior consensus
with respect to the applicability of DANE TLSA to "discovery" of
TLS enabled services.

I was not party to the original discussion of this topic, my
apologies if I am about to repeat previously discussed ideas.

The SMTP draft defines an opportunistically secure protocol.  For
inter-domain email on Internet scale, no domain has prior knowledge
of the set of peer domains (more specifically their MX hosts) that
support TLS.

Today's MTA employ TLS opportunistically, based on the offer of the
"STARTTLS" SMTP extension in the SMTP server's EHLO response.  This
offers no protection against MITM attacks (or even transient errors,
as many SMTP clients will retry in cleartext after TLS transmission

The DANE SMTP draft aims to provide a downgrade-resistant protocol
by which SMTP clients can determine (discover if you will) that a
given SMTP server support TLS and expects DANE SMTP clients to
avoid using cleartext delivery with the server.  The associated
TLSA records are used to authenticate the server to mitigate MITM
attacks that terminate TLS (rather simply suppress it).

If determining whether TLS support is required is incompatible with
DANE, I see no purpose for the SMTP draft.  We already unauthenticated
opportunistic TLS for SMTP (STARTTLS) which is vulnerable to various
downgrade attacks.  Without a secure signal to do TLS, the downgrade
attacks remain, and opportunistic TLS does not benefit from DANE.

So I hope the group can reach consensus that it is OK to use TLSA
records to discover a requirement for TLS.  This approach is not
new with the SMTP draft, it dates back to the original SRV draft
from Tony Finch, and is still stated in the revived version of that