[dnsext] MAR proposal #1: Algorithm downgrade protection

Samuel Weiler <weiler@watson.org> Fri, 01 April 2011 14:23 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 497163A684F for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.666
X-Spam-Level:
X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599]
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 DDTady4uDD1B for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:23:05 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 957523A6845 for <dnsext@ietf.org>; Fri, 1 Apr 2011 07:23:05 -0700 (PDT)
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 p31EOjsZ094365 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:24:45 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p31EOjfB094362 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:24:45 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 01 Apr 2011 10:24:45 -0400
From: Samuel Weiler <weiler@watson.org>
To: dnsext@ietf.org
In-Reply-To: <a06240800c9bb6f86edae@[10.31.200.112]>
Message-ID: <alpine.BSF.2.00.1104011022030.92106@fledge.watson.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> <20110314213319.A2799C8CA0B@drugs.dv.isc.org> <alpine.BSF.2.00.1103141750530.74870@fledge.watson.org> <a06240800c9a50cf4632a@10.31.200.110> <AANLkTimUUa5zkr+hZH4jR-euENg_n=9EwtRVBN-cxr9_@mail.gmail.com> <a06240802c9a7b6cb4cc3@192.168.1.105> <AANLkTin+hMZ-27VjkQq7_44zNguMiefhxbgGD+-XZxPP@mail.gmail.com> <a06240802c9a7e0807069@10.31.200.117> <AANLkTi=4co5mS3RYhK1BvUMOm54wgNAMeKtk3_Zm0ff1@mail.gmail.com> <a06240802c9a93d762e13@[10.31.200.112]> <a06240803c9a9417e1fe8@[10.31.200.112]> <4D938CC3.1020103@nlnetlabs.nl> <a06240800c9ba6184d535@[10.31.200.112]> <4D94DF2B.1040407@nlnetlabs.nl> <a06240800c9bb6f86edae@[10.31.200.112]>
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]); Fri, 01 Apr 2011 10:24:45 -0400 (EDT)
Subject: [dnsext] MAR proposal #1: Algorithm downgrade protection
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: Fri, 01 Apr 2011 14:23:06 -0000

This is a proposed change in DNSSECbis that arguably changes the 
mandatory algorithm rules.  I'm posting this as a summary of what I 
understand some may support, I don't support this change myself. 
Please post in this thread with your support or lack thereof.


In order to provide some protection against algorithm downgrade[1], 
we're defining a mechanism for zone signers to signal to validators 
that a SET of algorithms should ALL be checked, when possible, before 
determining that an answer from the zone is Secure.  Specifically, 
we're overloading the DS RRset to do that signalling.

Validators SHOULD check signatures from all algorithms present in a 
zone's DS RRset or trust anchors before declaring an answer from the 
zone to be Secure.  If it is impossible to validate an answer with one 
or more of those algorithms, the answer SHOULD be treated as Bogus.

This is a subset of the checks unbound was performing that let to the 
discovery of the problems with .cz's algorithm roll process.

Please post in this thread with your support or objections.