Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 21 February 2014 16:38 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 452791A01EC for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 08:38:30 -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 tJkiJRQqP1av for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 08:38:27 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 941C41A01EB for <dane@ietf.org>; Fri, 21 Feb 2014 08:38:27 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A44D2AAD11; Fri, 21 Feb 2014 16:38:22 +0000 (UTC)
Date: Fri, 21 Feb 2014 16:38:22 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140221163822.GT278@mournblade.imrryr.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org> <CAMm+LwiDQwPy0uj4ja=ngnwuAzqNLC28JV=4hk-Bu5F8UTdX8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwiDQwPy0uj4ja=ngnwuAzqNLC28JV=4hk-Bu5F8UTdX8A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UStnTLc3HVEkz1x07d33yQGS3OA
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: Fri, 21 Feb 2014 16:38:30 -0000
On Fri, Feb 21, 2014 at 09:42:06AM -0500, Phillip Hallam-Baker wrote: > > 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. For the record, my argument for DANE as a "TLS discovery" mechanism is strongly SMTP-specific. I make no claims about TLS discovery in other contexts. In MTA to MTA SMTP: - There is no signficant last-mile problem. The vast majority of MTAs don't globe-trot. - SMTP TLS security is opportunistic and sans DANE unauthenticated. We're using DANE to make possible an MITM downgrade-resistant opportunistic upgrade from cleartext to authenticated TLS. - SMTP is not a real-time protocol. - SMTP DNS lookups are not significantly latency impacting. Were gmail.com, for example, a DNSSEC signed zone, adding DANE would change the number of pre-connection DNS lookups for gmail.com in Postfix from 6 to 7. The local resolver caches the results ammortizing the cost over multiple deliveries. In fact gmail.com is not DNSSEC signed, and the SMTP draft explicitly suppresses TLSA lookups in zones where MX host A/AAAA records turn up "insecure" responses. Therefore, the cost of TLSA lookups for gmail.com with SMTP is currently ZERO. The main cost of DANE is incurred as soon as one enables a DNSSEC-aware recursive resolver on the MTA, whether for DANE or just to fend off Kaminsky cache poisoning. After that TLSA is basically free. Whatever concerns may exist for adding DANE to HTTP, do not apply to SMTP. It is somewhat unfortunate that the mindset around DANE TLSA is so HTTP-centric, since DANE is a much better fit for protocols other than HTTP. I plead that we not break DANE for SMTP just because it is perhaps a questionable fit for HTTP. If we stay focused on the problem at hand, the issue is quickly seen to be rather minor. -- Viktor.
- [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