Re: [dane] Behavior in the face of no answer?

John Gilmore <gnu@toad.com> Mon, 07 May 2012 23:16 UTC

Return-Path: <gnu@toad.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8C21F84B3 for <dane@ietfa.amsl.com>; Mon, 7 May 2012 16:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.35
X-Spam-Level:
X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khWww8iiEVb5 for <dane@ietfa.amsl.com>; Mon, 7 May 2012 16:16:38 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5021F84B5 for <dane@ietf.org>; Mon, 7 May 2012 16:16:38 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q47NGbcF013098; Mon, 7 May 2012 16:16:37 -0700
Message-Id: <201205072316.q47NGbcF013098@new.toad.com>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-reply-to: <A6208FF0-4544-470C-BBBD-5C4E328C6EC4@ICSI.Berkeley.EDU>
References: <20120504021044.GB4560@mail.yitter.info> <B25C977F-6B4E-458C-879D-A36EDB94DA75@icsi.berkeley.edu> <20120504023602.GA4683@mail.yitter.info> <CABcZeBO93n_C5detefBcOjAoswe2inGKDj65gQPDQmREyGnhAw@mail.gmail.com> <20120504112922.GB4929@mail.yitter.info> <CABcZeBPTTa07iUHo9XL5WrHGMYHwaQzs6xYtiF25O4Jek8E3RQ@mail.gmail.com> <20120504144426.GD4929@mail.yitter.info> <CABcZeBOM_0L42Rng75AsVda9u4G=FH8=OB8Qg=nQpL-BzRoBuQ@mail.gmail.com> <20120504165512.GC7394@mail.yitter.info> <CABcZeBO4zRSa=JexqZ8uw7o26tM4SZk2GDivTAWD5ZF1pZR9Og@mail.gmail.com> <20120504194132.GF7394@mail.yitter.info> <alpine.LFD.2.02.1205041553030.7798@bofh.nohats.ca> <AD11709E-F662-492E-BE3B-23ADD82536F0@icsi.berkeley.edu> <C8A32DF2-E912-4D53-B0E3-D79852632A3E@kumari.net> <C8244A46-63BD-4903-B72C-6AB43413FB61@ICSI.Berkeley.EDU> <DEED37B2-216E-44DA-8EDC-8E4271BDCBD5@vpnc.org> <A6208FF0-4544-470C-BBBD-5C4E328C6EC4@ICSI.Berkeley.EDU>
Comments: In-reply-to Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> message dated "Mon, 07 May 2012 08:23:06 -0700."
Date: Mon, 07 May 2012 16:16:37 -0700
From: John Gilmore <gnu@toad.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF DANE WG list <dane@ietf.org>
Subject: Re: [dane] Behavior in the face of no answer?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 07 May 2012 23:16:38 -0000

I think that if the DANE TLS implementation can't get either a
dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA
rrset, then to meet its security responsibilities, it has to fail to
connect.

Where the document is imprecise about that (or requires too many
indirections through obscure corners of the DNSSEC RFCs to understand
the implications) then I think we should say that more
straightforwardly in our RFC.

In browsers there will likely be a switch to "Use DANE TLS" just like
today there's a preference checkbox in Firefox for "Use SSL 3.0" and
"Use TLS 1.0".  When behind a broken coffeeshop gateway, the human may
need to manually turn off that switch.  But trying to operate in a
place that makes secure communication impossible should make enough
trouble for the user that they'll also complain to the coffeeshop
owner to fix their $*(@#@ gateway - or pick a different coffee shop
next time.

	John