Re: [dnsext] Clarifying the mandatory algorithm rules

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Thu, 18 November 2010 12:02 UTC

Return-Path: <wouter@nlnetlabs.nl>
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 7FCFD3A6826 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 04:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.287
X-Spam-Level:
X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1]
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 4Ji4HWM8Ij-z for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 04:02:13 -0800 (PST)
Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 4EA983A6765 for <dnsext@ietf.org>; Thu, 18 Nov 2010 04:02:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 166C75867F for <dnsext@ietf.org>; Thu, 18 Nov 2010 13:03:00 +0100 (CET)
Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 1A02F58658 for <dnsext@ietf.org>; Thu, 18 Nov 2010 13:02:54 +0100 (CET)
Message-ID: <4CE515ED.5010009@nlnetlabs.nl>
Date: Thu, 18 Nov 2010 13:02:53 +0100
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc13 Thunderbird/3.1.6
MIME-Version: 1.0
To: dnsext@ietf.org
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE50C01.4010104@nic.cz> <alpine.BSF.2.00.1011180630550.83352@fledge.watson.org>
In-Reply-To: <alpine.BSF.2.00.1011180630550.83352@fledge.watson.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.4 at rotring
X-Virus-Status: Clean
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 12:02:14 -0000

-----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-----