Re: [DNSOP] Definition of "validating resolver"

Willem Toorop <willem@nlnetlabs.nl> Mon, 09 March 2015 14:48 UTC

Return-Path: <willem@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651C61A8AC0 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 07:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Level:
X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 sjCDPusaJqg1 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 07:48:22 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E913F1A8AA8 for <dnsop@ietf.org>; Mon, 9 Mar 2015 07:45:55 -0700 (PDT)
Received: from [IPv6:2a04:b900:0:1:919d:51db:3fec:299] (unknown [IPv6:2a04:b900:0:1:919d:51db:3fec:299]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D30BC28CB for <dnsop@ietf.org>; Mon, 9 Mar 2015 15:45:53 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1425912353; bh=ICXjgC8LVuO+9X2ZOr1M3VooY1vaD8Az0UomL1E0UfM=; h=Date:From:To:Subject:References:In-Reply-To; b=es0MqSwsaKVkoMHR4iSk+eLLBnlHrBIwtgLRbzk47YT3NvcVFl6Nx5HXFYb2HQgJm hPWA20OxdjFl6Qmxp+8ALCq1ke69iVVUsJveYowkQEqIUADpo9pCJZL1qrjP6Jcb8V tRkVtriTDLI9Fxodx2KdiYJHxJRyX3oS80PRYRL8=
Message-ID: <54FDB221.8020903@nlnetlabs.nl>
Date: Mon, 09 Mar 2015 15:45:53 +0100
From: Willem Toorop <willem@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <DED3D224-C507-4751-808C-3D881A238942@vpnc.org> <20150308223157.GA2770@PorcupineTree>
In-Reply-To: <20150308223157.GA2770@PorcupineTree>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/NmQA9FZl3nhDcPO4PLgKCh99VIM>
Subject: Re: [DNSOP] Definition of "validating resolver"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 14:48:24 -0000

I'd like to maintain the term exactly as specified in RFC4033
(understanding DNSSEC but not validating), because it comes in use when
talking about validating stubs.

Some network operators don't know or care about DNSSEC and do not equip
their network's resolver with a trust anchor.  Such a resolver is
obviously not validating, but if it is a modern resolver it is very
likely to be security-aware.

An application using a validating stub can leverage such a resolver to
get DNSSEC answers from the cache which it can then validate itself.
For example to get an authenticated TLSA and bootstrap an encrypted channel.

I have presented measurements on the amount of security-aware resolvers
in RIPE ATLAS in the context of this use case at ICANN50:

https://london50.icann.org/en/schedule/wed-dnssec/presentation-dnssec-validation-deployment-25jun14-en.pdf

Though in the research we called those DNSSEC-aware instead of
security-aware.

-- Willem

Op 08-03-15 om 23:31 schreef Ralf Weber:
> Moin!
> 
> On Sun, Mar 08, 2015 at 12:21:49PM -0700, Paul Hoffman wrote:
>> Greetings again. Paul Wouters noticed an inconsistency in the terminology
>> draft, and upon investigation, I believe it is a problem (hopefully
>> fixable) with the definitions in RFC 4033.  RFC 4033 and 4035 use the term
>> "validating resolver" in a few places.  However, RFC 4033 never defines
>> that.  RFC 4033 *does* define "security-aware resolver":
>>
>>    Security-Aware Resolver: An entity acting in the role of a resolver
>>       (defined in section 2.4 of [RFC1034]) that understands the DNS
>>       security extensions defined in this document set.  In particular,
>>       a security-aware resolver is an entity that sends DNS queries,
>>       receives DNS responses, supports the EDNS0 ([RFC2671]) message
>>       size extension and the DO bit ([RFC3225]), and is capable of using
>>       the RR types and message header bits defined in this document set
>>       to provide DNSSEC services.
>>
>> My personal interpretation is that "validating resolver" is a synonym for
>> "security-aware resolver".  Do others agree?  If not, how would you
>> differentiate them?
> I was told that the difference is that a security aware resolver does
> not validate, but instead relies on the "Validating Stub Resolver" to 
> protect the user. So it would handle all the DNSSEC processing to the
> authoritative and would store the records with signatures in the cache,
> but it wouldn't check if they are valid. 
> 
> The people who told me that interpreation of the RFC never did deploy DNSSEC
> and thankfully most of the people who did and deployed DNSSEC used
> validating and security aware resolvers. I don't think it makes sense to
> deploy a caching resolver without validation.  So would be ok if we define
> it as you suggest.