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

Nicholas Weaver <nweaver@icsi.berkeley.edu> Fri, 21 February 2014 15:01 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 B3A3E1A0179 for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 07:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 qvtLrJcpR1CZ for <dane@ietfa.amsl.com>; Fri, 21 Feb 2014 07:01:23 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id DE5D41A0172 for <dane@ietf.org>; Fri, 21 Feb 2014 07:01:22 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3B4BE2C402A; Fri, 21 Feb 2014 07:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L767yMibcsDL; Fri, 21 Feb 2014 07:01:16 -0800 (PST)
Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 90A8E2C400A; Fri, 21 Feb 2014 07:01:16 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BDCABE8E-3F0B-4FCF-ADBF-F8426A820BF9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <CAMm+LwiDQwPy0uj4ja=ngnwuAzqNLC28JV=4hk-Bu5F8UTdX8A@mail.gmail.com>
Date: Fri, 21 Feb 2014 07:01:16 -0800
Message-Id: <DE057EDD-22E0-4268-8C81-A276761C0F97@icsi.berkeley.edu>
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>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wKZYwL4ArkVqvexKubn0fKMqBgM
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "<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 15:01:24 -0000

On Feb 21, 2014, at 6:42 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> 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 client can know.  It starts by asking for DNSKEY for ., etc.  Because you have NSEC/NSEC3 provable denial of existence, you can know if DNSSEC records are being stripped.


In particular, the problem for this tends to be internet cafes and the like.  Home networks tend to be atrocious on the DNS proxies, but the client can usually go around them and get things directly.  Business network firewalls may restrict client DNS, but they usually operate properly and the recursive resolver itself supports DNSSEC.

Its the net cafes, hotels, etc (basically, anything with a captive portal) which combines both a crappy DNS proxy AND DNS access restrictions that is the problem.

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

Agreed, with a minor caveat.  

The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc