IETF Logo Mail Archive

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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Mon, 07 May 2012 15:56 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
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 40C6921F85D1 for <dane@ietfa.amsl.com>; Mon, 7 May 2012 08:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
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 BfQMzgs7-aFj for <dane@ietfa.amsl.com>; Mon, 7 May 2012 08:56:27 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C867C21F849D for <dane@ietf.org>; Mon, 7 May 2012 08:56:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9E2AD2C400B; Mon, 7 May 2012 08:56:27 -0700 (PDT)
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 IRf2xJWbQMea; Mon, 7 May 2012 08:56:27 -0700 (PDT)
Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5D31B2C4002; Mon, 7 May 2012 08:56:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <B03C9DB5-9D31-43D6-8C9F-659A8871D33B@vpnc.org>
Date: Mon, 7 May 2012 08:56:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A43EA9C9-5C6B-4594-9695-BA33DF22D7DB@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> <B03C9DB5-9D31-43D6-8C9F-659A8871D33B@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1257)
Cc: 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 15:56:28 -0000

On May 7, 2012, at 8:43 AM, Paul Hoffman wrote:

> If you believe that we should only standardize the perfect, not the good, that's fine. Others seek to standardize the good which can be upgraded to the perfect with no flag days, which is what is proposed here.

No, I believe we should standardize the good.

If you wish to standardize the almost useless but can be upgraded to good with no flag day, but which upgrading to good requires replacing or bypassing a significant amount of brokenness on the Internet, say so.

Because DANE without nearly-hard-fail [1] on no data, not just BOGUS data, AND client-side validation, is no different that browser CRLs in terms of protection to the users in the face of an actual attack.



[1] namely, allow the user to bypass but scream bloody murder about it...

v2.8.7 | Report a Bug | By Email