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/
- [dane] Lukewarm discussion: DANE for opportunisti… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… James Cloos
- Re: [dane] Lukewarm discussion: DANE for opportun… Peter Saint-Andre
- Re: [dane] Lukewarm discussion: DANE for opportun… Paul Hoffman
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… James Cloos
- Re: [dane] Lukewarm discussion: DANE for opportun… Warren Kumari
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… Phillip Hallam-Baker
- Re: [dane] Lukewarm discussion: DANE for opportun… Jelte Jansen
- Re: [dane] Lukewarm discussion: DANE for opportun… Nicholas Weaver
- Re: [dane] Lukewarm discussion: DANE for opportun… Paul Wouters
- Re: [dane] Lukewarm discussion: DANE for opportun… Nicholas Weaver
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni