Re: [dnsext] Clarifying the mandatory algorithm rules
Mark Andrews <marka@isc.org> Mon, 14 March 2011 23:18 UTC
Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642EA3A6EF3 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 16:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level:
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_41=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4m-Pp9OQDrp for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 16:18:41 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id DCA0F3A6B8B for <dnsext@ietf.org>; Mon, 14 Mar 2011 16:18:40 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7684C5F985D; Mon, 14 Mar 2011 23:19:49 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 44251216C1E; Mon, 14 Mar 2011 23:19:47 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 57DA6C8D90F; Tue, 15 Mar 2011 10:19:45 +1100 (EST)
To: Brian Dickson <brian.peter.dickson@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE51293.5040605@nlnetlabs.nl> <a06240801c9101620d463@192.168.128.163> <22284.1290447209@nsa.vix.com> <4CF4D54B.5000407@nlnetlabs.nl> <20110310223438.978E9C0E902@drugs.dv.isc.org> <4D79DDFA.3010006@nlnetlabs.nl> <alpine.BSF.2.00.1103140901170.99213@fledge.watson.org> <a06240800c9a3c90e2f16@10.31.200.110> <AANLkTikKPPoJRnp_7xgxoirBhkyA2=Z6E8g-Eenju8dp@mail.gmail.com>
In-reply-to: Your message of "Mon, 14 Mar 2011 12:09:27 -0300." <AANLkTikKPPoJRnp_7xgxoirBhkyA2=Z6E8g-Eenju8dp@mail.gmail.com>
Date: Tue, 15 Mar 2011 10:19:45 +1100
Message-Id: <20110314231945.57DA6C8D90F@drugs.dv.isc.org>
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, dnsext@ietf.org
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Mar 2011 23:18:42 -0000
In message <AANLkTikKPPoJRnp_7xgxoirBhkyA2=Z6E8g-Eenju8dp@mail.gmail.com>, Bri an Dickson writes: > On Mon, Mar 14, 2011 at 10:41 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote: > > At 9:10 -0400 3/14/11, Samuel Weiler wrote: > > > >> then presumably we're also changing what it means to be a "properly sign= > ed > >> zone". =A0What's the new definition? =A0And why that change? > > > > Although Sam wrote this, I'm not assuming this is his opinion. > > > > To a validator, whether or not a zone is properly signed should be > > immaterial. =A0A validator's concern is whether a set of data is properly > > authenticated. > > > > The switch from "signed" to "authenticated" is on purpose, yet subtle. = > =A0The > > reason I switched is to switch from a voice of "supply side" to "demand > > side." > > > > As a supply side'r, I'm concerned with how something is accomplished. > > Signing is one basic unit in DNSSEC. =A0And making sure the zone is prope= > rly > > signed is my goal. =A0"Properly" is relative to the specifications, the r= > ole > > of the specs is to set up expectations on the other side. > > > > As a demand side'r, I'm concerned with what has been done. Authenticating > > the data is what I am achieving. =A0Authenticating involves first setting= > the > > expectation of whether I get the data I need (the RRSIG) and then seeing = > if > > the expectation is met. > > > > What I am cautioning against is the degree to which a demand side'r goes = > to > > determine expectations. =A0A paranoid demand side'r almost looks for excu= > ses > > to declare data unauthentic, and that's bad. =A0A lazy demand side'r avoi= > ds > > looking as much as possible, and that's just as bad. =A0A happy medium is > > needed. > > > > A happy medium to me is one where the focus is goal-oriented. =A0If the d= > ata > > has a valid signature and I can use a chain of keys up to a trusted ancho= > r, > > then I declare victory. =A0There's no security problem with that. > > > > So, when it comes to validation, we should not even have a definition of > > "properly signed zone." =A0That is in the domain of the signer. > > While technically correct, I think there is a holistic concern. > > All who use DNSSEC, have a vested interest in ensuring that it is, on > the whole, as secure as possible. There is secure as possible and to strict. > One facet of this is, maximizing the risk of detection of both > successful attacks, and unsuccessful attacks, on the validation side. > > Observation The beauty of DNSSEC is, the data is secured (protected by > crypto signatures), so the particular source of the data (direct from > authority servers, or indirect from arbitrary caches) is irrelevant, > and so the transport doesn't need to be protected. This already > presumes that the data source (i.e. whatever server answers a query, > e.g. iterative resolver) isn't trusted per se. The presumption has to > be, that answers may be modified or replaced, somehow, by someone, and > that we are protecting ourselves from trusting those modified/replaced > answers by the protections afforded by DNSSEC. The basic problem is, a > validator cannot distinguish between incorrectly signed data (where > not all the promised algorithms have been used, "promised" =3D=3D present > in the DS), and answers which have been selectively modified by an > attacker. > > An attacker can either strip all but one signature, and replace that > signature with a forged signature, which matches the forged data; or > the attacker can leave now-invalid signatures along with the forged > signature and forged data. Which requires the zone to be signed with a incredibly weak key or the private key to be compromised. > The first level of defense, the most trivial, is the downgrade > prevention. There needs to be a proof of an answer being from an > insecure zone, before we believe an answer which has no RRSIG. Which the validators all do. > The second level of defense, the one which is not universally agreed > as necessary, is the protection against a limited substitution with a > single forged signature. Which provably cannot be done with seperate DNSKEY and DATA lookups. The only way to achieve that reliably is to return the DNSKEY RRset along with every DATA lookup and cache the combined answer so that the correct DNSKEY RRset can be returned with the DATA. > This is where the holistic approach may be a good compromise between > the believers and unbelievers (of the risk of such a signature ever > being possible): > > (The following presumes more than one algorithm is in use, and thus, > that one or more algorithms now no longer has a valid signature.) > > If the validation process is driven by the processing of RRSIGs, and > only indirectly checks algorithms, the first form of substitution will > go unnoticed. IMHO, this is unwise. > > If the validation process is driven by first determining the > algorithms, and then checking signatures, the first form of > substitution will be detected. (See below for "what to do".) > > In both cases, the second form of substitution *may* be detected, > depending on which RRSIG is checked first, and/or whether all > algorithms need to have an RRSIG successfully validated. (Also see > "what to do".) > > Randomizing among the algorithms in the intersection set of "known by > the validator" and "present in the DS RRSET", ensures the probability > of detection is non-zero. > > Non-zero detection is the goal -- noticing that something is up, > either because of an erroneous zone signing, or because of an attack. > > What To Do > > This is a question balancing the issue of false positives, with true > positives. The choices are, report "bogus", and log, or report "valid" > but log. > > For sure, logging on the validator is practically mandatory, or at > least should be supported by implementers. Alerting back to the > authority server operator may or may not be appropriate to automate. > > Logging by stub resolvers is not likely to be useful. > > IMHO, the best choices are: randomize on algorithms, validate but log, > and have validator operators support folks (where appropriate) > investigate issues as they arise. It is probably too early to know the > rate of false positives, but that is something that operators should > likely be tracking. > > The main thing is, to be able to assure would-be attackers that > *someone* will notice if/when they decide to try, and that that should > hopefully be enough of a deterrent to provide value to the whole of > the consumers of DNSSEC to justify its use. > > Brian > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- Re: [dnsext] Clarifying the mandatory algorithm r… Jeffrey A. Williams
- [dnsext] Clarifying the mandatory algorithm rules Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Florian Weimer
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… George Barwood
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Doug Barton
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Jelte Jansen
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Ondřej Surý
- Re: [dnsext] Clarifying the mandatory algorithm r… Paul Vixie
- Re: [dnsext] Clarifying the mandatory algorithm r… W.C.A. Wijngaards
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Phillip Hallam-Baker
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Olafur Gudmundsson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Alfred Hönes
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Brian Dickson
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- Re: [dnsext] Clarifying the mandatory algorithm r… Mark Andrews
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Casey Deccio
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Matthijs Mekking
- Re: [dnsext] Clarifying the mandatory algorithm r… Edward Lewis
- Re: [dnsext] Clarifying the mandatory algorithm r… Samuel Weiler
- [dnsext] MAR proposal #1: Algorithm downgrade pro… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Samuel Weiler
- [dnsext] MAR proposal #2: Allowing pre-publishing… Samuel Weiler
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Edward Lewis
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Edward Lewis
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Mark Andrews
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Paul Hoffman
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Paul Hoffman
- Re: [dnsext] MAR proposal #1: Algorithm downgrade… Brian Dickson
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Marc Lampo
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Matthijs Mekking
- Re: [dnsext] MAR proposal #2: Allowing pre-publis… Joe Abley
- Re: [dnsext] Clarifying the mandatory algorithm r… weiler