Re: [dnsext] Clarifying the mandatory algorithm rules
Phillip Hallam-Baker <hallam@gmail.com> Thu, 18 November 2010 13:45 UTC
Return-Path: <hallam@gmail.com>
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 E4E883A657C for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 05:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 mh7Vg2v1985p for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 05:45:17 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 581923A6452 for <dnsext@ietf.org>; Thu, 18 Nov 2010 05:45:17 -0800 (PST)
Received: by gxk27 with SMTP id 27so1956355gxk.31 for <dnsext@ietf.org>; Thu, 18 Nov 2010 05:46:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=MCj0z33nf1hO/TOs/+WlinS8y3AE1GW8IfZaGg7xli8=; b=X2zdPBUe24etzpmZcBVwI3wiWYpwAkBV6dgBZ37I2qftsvMQ0g86ebFX6raFywAqTE zFqpZ0tiJgh7Iq19tI+VbmbPy/tl6VpbP0dZqE1d3aV7Qw/YXPw4kPKDTXOgTKuV+Q+o ED02BOIQ6n0AycAoKFZppX78Tj/40RJnxuowg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fh+9y9fTZGYGgV2jqMbkaW2d4sg01WYxnxv2vcFTqDJO7y7JJHXo8QyztaSrfSTBwM xJNImSlaYb/r4RnEkhI8AGmDEwasRKiyOUR6GMpWe4K1Z8uV2YPaS8IRamTTA6pN/oQA IJ2EzYg19M7iONNsJxgXsVvvXRU//taFdLU18=
MIME-Version: 1.0
Received: by 10.100.138.16 with SMTP id l16mr528141and.0.1290087964355; Thu, 18 Nov 2010 05:46:04 -0800 (PST)
Received: by 10.100.41.14 with HTTP; Thu, 18 Nov 2010 05:46:04 -0800 (PST)
In-Reply-To: <4CE515ED.5010009@nlnetlabs.nl>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE50C01.4010104@nic.cz> <alpine.BSF.2.00.1011180630550.83352@fledge.watson.org> <4CE515ED.5010009@nlnetlabs.nl>
Date: Thu, 18 Nov 2010 08:46:04 -0500
Message-ID: <AANLkTikmD0rdt=pYDn+Z3u-F3cmiLTgxUO=0=nOTBy--@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
Content-Type: multipart/alternative; boundary="0016e6434ae8d82eeb049554029c"
Cc: 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: Thu, 18 Nov 2010 13:45:19 -0000
I can't quite understand why we would make a change to require acceptance of the unsigned zone in this case. 1) What is easier, for operators to change their behavior and sign before they publish keys or for resolvers to change their behavior. 2) What is more secure, to protect against the downgrade attack or to allow it for the sake of incompetent signers? 3) What is more sustainable? If the WG accepts this change, what is the probability others will implement a choice that appears eccentric and wrong? Absent a really compelling reason to allow for zones to be signed in this way, I can't see why we would not change the operations section rather than the validation. Is there any reason that the operators cannot publish the signatures before the keys? The problem of what relying applications should to do when a zone is incorrectly signed is much more general than this one example and one that I don't think has been fully considered by those advocating end-to-end DNSSEC design with the validation taking place at the relying application. This is a general problem in cryptographic protocols: if there is no possibility of an attack succeeding, there is no point in attempting the attack. Therefore the probability that a signature is failing because of an attack falls to zero and the overwhelming likelihood is that the cause of any failure is misconfiguration. There are controls that can be implemented to mitigate this but they depend on having more state information than an endpoint can acquire on its own. On Thu, Nov 18, 2010 at 7:02 AM, W.C.A. Wijngaards <wouter@nlnetlabs.nl>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Sam, > > You seem to want to enforce an original idea (which Mark understood > perfectly, it seems), about protection from signature-missing. This is > not what RFC4035 says. > > On 11/18/2010 12:37 PM, Samuel Weiler wrote: > > On Thu, 18 Nov 2010, Ond?ej Sur? wrote: > > This is a different sort of downgrade attack than the one these rules > > were designed to protect against. Indeed, to address this attack within > > the protocol, we'd need to require resolvers to check EVERY algorithm's > > signature (if they can). We didn't do that before, and it's probably > > unwise to make that change now. > > That is what unbound does. And it gets algorithm downgrade protection > security as a benefit (for the algorithms that it implements). > > Since owners MUST sign their zone correctly, I see no need to specify a > MUST accept missing signatures if you implement the other algorithm? > Why do you want to allow inproperly-signed zones? It will break > resolvers that implement only a subset of algorithms? > > > Indeed, for the attack you're describing, the resolver would need to be > > involved, and it would need to change. > > Unbound would not need to change. Today, if people sign their zones > properly, this is compatible with BIND and Unbound. > > Because it is unknown if future algorithm numbers may allow signatures > to be absent; unbound does not check if signatures are missing for > algorithms that it does not implement (and anyway a spoofed signature > would trivially get accepted since it cannot validate). > > > The downgrade attack that led to this is documented in a message to > > namedroppers on 13 August 2003, Subject line "DNSSECbis Q-2: degradation > > attack". With the archives off-line, perhaps I should resend it. > > No. > > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkzlFe0ACgkQkDLqNwOhpPjODACcCjh2uSefIUiMUdTtpJit9yfa > 5fEAn2aYmizlQcZm4sJVQgjfFv/FJSEj > =I/FY > -----END PGP SIGNATURE----- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/
- 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