Re: [dnsext] MAR proposal #1: Algorithm downgrade protection

Samuel Weiler <weiler@watson.org> Fri, 01 April 2011 14:24 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 1A6383A6845 for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level:
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 ea4xiIjYccsx for <dnsext@core3.amsl.com>; Fri, 1 Apr 2011 07:24:48 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 692003A684F for <dnsext@ietf.org>; Fri, 1 Apr 2011 07:24:48 -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 p31EQSRR094528 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:26:28 -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 p31EQSV1094525 for <dnsext@ietf.org>; Fri, 1 Apr 2011 10:26:28 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 01 Apr 2011 10:26:28 -0400
From: Samuel Weiler <weiler@watson.org>
To: dnsext@ietf.org
In-Reply-To: <alpine.BSF.2.00.1104011022030.92106@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.1104011025380.92106@fledge.watson.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org> <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]> <alpine.BSF.2.00.1104011022030.92106@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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:26:28 -0400 (EDT)
Subject: Re: [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:24:49 -0000

On Fri, 1 Apr 2011, Samuel Weiler wrote:

> In order to provide some protection against algorithm 
> downgrade[1]...

I forgot to provide the footnote in my first message:

[1] Acknowledging that some algorithms may eventually become weak, but
such weaknesses may not be as clear and binary as "yesterday the
algorithm was secure and today it is totally broken", a zone signer
might wish to provide signatures from a more secure algorithm so that
newer validators can be protected while simultaneously providing older
(weak) signatures for the benefit of validators that have not been
upgraded.  Without a signaling mechanism such a this, a validator
supporting both old and new algorithms may find itself accepting
forged answers signed only with the old (and broken!) algorithm.

Alternatives to this mechanism include disabling the broken algorithm
in the validator (which could unnecessarily prevent validation of
zones that haven't signed with something stronger) or implementing a
preference system in the validator (e.g. "if the zone is signed with
WeakAlgA and StrongAlgB, ONLY check the signatures from StrongAlgB").