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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 21 February 2014 14:42 UTC

Return-Path: <hallam@gmail.com>
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 400921A018B for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 06:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Hqx2m_war-Ux for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 06:42:12 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7291A0316 for <dane@ietf.org>; Fri, 21 Feb 2014 06:42:11 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id e16so2369092lan.26 for <dane@ietf.org>; Fri, 21 Feb 2014 06:42:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2/plgab7eAUqik2yRzz6RP0u2uv+7eCHn9WlqeBN4Bs=; b=vz/KbbLqdji0UnIuU3bAR9g+gJHu/9pclJy0icJxcrESVK+6Oa19Whl+5ww/rOsZEI UuUhR03i/uerpNx1qQl6jYG+b4Y7aelESd3AjOsTRrdqeU+/uRYQOzAbDoEOMeHkOU87 eGPcWR6vvnBYYhSm0qwZmWve7mXXncuyW89OCOfY2nJ/+6E6mRZNjz68wM8Oh3gyiLDd JCz+LY4BEQFwFtklD0bK7iQR5rhfz5V+eR1QhEwR50oAU8nd4gfgPLMSFYOU/snLFdHs wlrvG9zJuqLDTcWA+Y67vowLYPehzhWVlptkfkEnRaePRyxeoJWQnPxXkS6TZA1O2QJn ROaQ==
MIME-Version: 1.0
X-Received: by 10.112.39.167 with SMTP id q7mr4254525lbk.82.1392993726533; Fri, 21 Feb 2014 06:42:06 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Fri, 21 Feb 2014 06:42:06 -0800 (PST)
In-Reply-To: <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org>
Date: Fri, 21 Feb 2014 09:42:06 -0500
Message-ID: <CAMm+LwiDQwPy0uj4ja=ngnwuAzqNLC28JV=4hk-Bu5F8UTdX8A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a1134d7ae3e969404f2eba0f0
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KNY7Ofd-eJF9h41s9BXEBaNstck
Cc: "<dane@ietf.org>" <dane@ietf.org>
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: Fri, 21 Feb 2014 14:42:15 -0000

On Fri, Feb 14, 2014 at 7:48 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> 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.
>

I argued for making DANE a security policy protocol at the start. Now you
are wondering if what you produced works as a security policy protocol. It
can but the critical mass for adoption is almost certainly too high.

DNS resource records are cheap. DNS lookups are not cheap.

DANE has a last mile problem because you can't know if the DNSSEC record
has been stripped out by an attacker or by some local network firewall.


The way to cut the Gordian knot here is to provide an efficient way to
retrieve all the information necessary to set up a request in one lookup.
That solves the last mile problem and the multiple lookup problem at the
same time.

-- 
Website: http://hallambaker.com/