IETF Logo Mail Archive

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

Andrew Sullivan <ajs@anvilwalrusden.com> Fri, 04 May 2012 16:55 UTC

Return-Path: <ajs@anvilwalrusden.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 AD1E621F8648 for <dane@ietfa.amsl.com>; Fri, 4 May 2012 09:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.63
X-Spam-Level:
X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 h+OhEeW-H26R for <dane@ietfa.amsl.com>; Fri, 4 May 2012 09:55:15 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F721F8638 for <dane@ietf.org>; Fri, 4 May 2012 09:55:15 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7C0951ECB41C for <dane@ietf.org>; Fri, 4 May 2012 16:55:14 +0000 (UTC)
Date: Fri, 4 May 2012 12:55:12 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dane@ietf.org
Message-ID: <20120504165512.GC7394@mail.yitter.info>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABcZeBOM_0L42Rng75AsVda9u4G=FH8=OB8Qg=nQpL-BzRoBuQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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:55:16 -0000

On Fri, May 04, 2012 at 08:10:40AM -0700, Eric Rescorla wrote:
> > we usually call "NODATA".  The case I mentioned yesterday, where AD is
> > set and the upstream doesn't give you the DNSSEC data and you have a
> > NODATA response is, AFAICT, just a case where there is no TLSA RRset
> > and shouldn't result in TLS failure.
> 
> But the problem is that this is indistinguishable from the case where there
> *was* a TLSA RRSET and you have a network attacker.

It certainly isn't.  If you're depending on your upstream validator,
you need to trust it.  If you don't trust it, don't depend on the
upstream, in which case you're not going to offload validation.

A NODATA answer is _not_ just like "no response at all" if the answer
passed validation, and if it didn't pass the the specification already
covers this case.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.8.7 | Report a Bug | By Email