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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 15 February 2014 00:48 UTC

Return-Path: <paul.hoffman@vpnc.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 868971A00DE for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 16:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 YEW_Q83K5VOQ for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 16:48:39 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 390A11A00A7 for <dane@ietf.org>; Fri, 14 Feb 2014 16:48:39 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1F0mXVw075903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Fri, 14 Feb 2014 17:48:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <m37g8x2trc.fsf@carbon.jhcloos.org>
Date: Fri, 14 Feb 2014 16:48:32 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org>
To: "<dane@ietf.org>" <dane@ietf.org>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NAEbPFdvrKcnho0q-HtAF4kdfD4
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
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: Sat, 15 Feb 2014 00:48:40 -0000

On Feb 14, 2014, at 2:50 PM, James Cloos <cloos@jhcloos.com> wrote:

> The only real question is whether dane-srv and dane-smtp-with-dane
> should be published as two rfcs or combined into one?
> (I’m leaning towards two, numerically adjacent.)

With all due respect, there are other real questions, much more significant than that one.

One of the biggest questions that needs to be asked is not whether DANE can be used for opportunistic protocols, because of course it can, but whether DANE can be used to determine whether a server at a domain name "should" be speaking TLS at the time that a client tries to connect. Viktor makes a strong case that it does for SMTP. During the early discussions of TLSA, many people thought it should not.

Viktor's view gives us good MITM protection if the DNS channel is not broken and the client knows the DNSSEC status of its query. It also causes messages to be lost if there is an operational problem or even an unexpected mis-match on the crypto desires of the client and server. It also assumes that the person running the DNS server for a name is in active contact with the person operating the SMTP server.

Personally, I don't care about MITM protection if it comes at the cost of getting more organizations to turn on opportunistic crypto. I think DANE still has an important role in that it gives the SMTP server operator a logging capability to see if there is an MITM. Others prefer more protection against MITMs even in the face of preventable communication failures.

And, to be blunt, if we think that Viktor is right about DANE for SMTP, shouldn't DANE for HTTP have the same MITM protection and operational downsides?

--Paul Hoffman