Re: [dnsext] Clarifying the mandatory algorithm rules

Samuel Weiler <weiler@watson.org> Thu, 18 November 2010 11:37 UTC

Return-Path: <weiler@watson.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 9BF793A682B for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 03:37:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level:
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3]
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 MOwSHs+EtKFH for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 03:37:03 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id EFD9C3A6830 for <dnsext@ietf.org>; Thu, 18 Nov 2010 03:37:02 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oAIBbnMG090856; Thu, 18 Nov 2010 06:37:50 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oAIBbnA2090851; Thu, 18 Nov 2010 06:37:49 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 18 Nov 2010 06:37:49 -0500
From: Samuel Weiler <weiler@watson.org>
To: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <4CE50C01.4010104@nic.cz>
Message-ID: <alpine.BSF.2.00.1011180630550.83352@fledge.watson.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <4CE50C01.4010104@nic.cz>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 18 Nov 2010 06:37:50 -0500 (EST)
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 11:37:04 -0000

On Thu, 18 Nov 2010, Ond?ej Sur? wrote:

> 1) there is a known cryptographic attack against algorithm A
...
> 7) if the validating resolver is OK with just one or another and not 
> both algorithm signatures, it could be convinced to validate the result 
> just by seeing (spoofed) signatures with algorithm A.  So the validating 
> resolver sees spoofed records and it's spoofed signatures using just 
> algoritm A and it validates the result.

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.

The current work-around is for the zone owner to STOP signing with the 
known-broken algorithm A.  That leaves code that only supports A out 
in the cold.  If you're assuming resolvers support both A and B 
(as your clarification says), there's no problem.

> What do I miss here?  I really do think that there is no downgrade 
> attack protection if it's not implemented on both sides (authoritative 
> and validating-recursive).

Indeed, for the attack you're describing, the resolver would need to 
be involved, and it would need to change.

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.

-- Sam