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

Adam Langley <agl@imperialviolet.org> Fri, 04 May 2012 16:18 UTC

Return-Path: <alangley@gmail.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 B9B1821E8024 for <dane@ietfa.amsl.com>; Fri, 4 May 2012 09:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 bdDBQWID0SRU for <dane@ietfa.amsl.com>; Fri, 4 May 2012 09:18:21 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED4A21E8020 for <dane@ietf.org>; Fri, 4 May 2012 09:18:21 -0700 (PDT)
Received: by dadz9 with SMTP id z9so4803089dad.39 for <dane@ietf.org>; Fri, 04 May 2012 09:18:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XYxT4iIGKQfSh2Q+ddBEEzMB0T+7MOa2Cp0Dlcp+sm0=; b=nvqLMQKHrf4/InKfNJZKxdLFq7ZW1CmeI3ePRsaGCT56FYdC+md6YXwOGCGr9D+Iex oE7o/dPDhdw9Q3ZG2cV54rZmDtrDEaft0QpnMPsZkusVXyavnY33nE9zHStvFIpNIoGT 1FfMmdbhAh4mwpFfS40porfi0cCsmHy/y2oXgfT/9lHnKZbG4gj+K/L5QC76w1sPeeSN u8CSMesx6jsZmGwQRalIH4+bnK18mfH3EQgWhMwMM2WdVGtYspxus49SYDc5qVQMca7E RgqqHOMVlcMG7NRSFiXE4ZU8UoNNAjFssKumByxifVYsF3iMEUSb09k/lHF1MqnJBeVE uB0g==
MIME-Version: 1.0
Received: by 10.50.186.168 with SMTP id fl8mr3403171igc.68.1336148300715; Fri, 04 May 2012 09:18:20 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.42.76.7 with HTTP; Fri, 4 May 2012 09:18:20 -0700 (PDT)
In-Reply-To: <CABcZeBP2iRLa76rSXu4A0OwFxP=tqK1ShZ6wv=6wnaEC6uad+w@mail.gmail.com>
References: <CABcZeBMY26xrfvAx=UsYN2XnuONZ2vPy9tNwHQALudd=yQDvgA@mail.gmail.com> <0526D60A-3F1B-4C55-9796-256BC2556AAB@vpnc.org> <20120503223745.GC1804@mail.yitter.info> <CABcZeBMFV8oiZJfAY1fZ_0bBQWa=q6aBL65AS+W5gBuKmPnwOg@mail.gmail.com> <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> <3FF36EBA-F8B1-4D66-BA00-E8E36A7E449D@kumari.net> <CABcZeBP2iRLa76rSXu4A0OwFxP=tqK1ShZ6wv=6wnaEC6uad+w@mail.gmail.com>
Date: Fri, 4 May 2012 12:18:20 -0400
X-Google-Sender-Auth: LpjljOAj5SMv3i-eF8ujCaZbJpo
Message-ID: <CAMfhd9XYS=9SGotCTwa7NJU4L8WFys2rDVsQZxn4a0wz+NxS3Q@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: 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: Fri, 04 May 2012 16:18:21 -0000

On Fri, May 4, 2012 at 12:08 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Before we discuss how to proceed, I think it would be useful to get agreement
> on the security analysis. I claim that for Usages 0 and 1, treating
> TLSA non-response
> as if no TLSA records exist means that DANE adds minmal/no security
> value for those
> usages.

I believe that you're completely correct.

Browsers are not going to enable DANE hard fail in the short or medium
term because of the fraction of clients that have broken DNS and can't
fetch the records.

Therefore, browsers are not going to see a security benefit from DANE.
The DNSSEC stapled certificates that Tom points to are addressing a
very different use case: people who would otherwise use self-signed
certificates and who get annoyed that we throw errors for them.

However, browsers are not the world. Other clients, which may benefit
from a smaller, more controlled, deployment may be able to enforce
DANE hard-fail and see security benefits.

I would personally suggest that the spec requires hard fail, or at
least discusses the fact that, without hard-fail, the security
benefits are moot. Implementations frequently ignore requirements in
specs, but rarely add to them!


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org