Re: [dnsext] Clarifying the mandatory algorithm rules

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 18 November 2010 15:10 UTC

Return-Path: <brian.peter.dickson@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 16DBB3A6827 for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 07:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.825
X-Spam-Level:
X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 9QM2XXvGJIif for <dnsext@core3.amsl.com>; Thu, 18 Nov 2010 07:10:06 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 73D293A67E7 for <dnsext@ietf.org>; Thu, 18 Nov 2010 07:10:03 -0800 (PST)
Received: by yxd39 with SMTP id 39so2016711yxd.31 for <dnsext@ietf.org>; Thu, 18 Nov 2010 07:10:51 -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 :content-transfer-encoding; bh=I6Ck8AadQvpOPcIWGx3TlGqJ1YKdeP8uYl5poSZd1HQ=; b=tX3lzpFDsiamHsoGVphuH9uPCT2/oyv10iCWXBcZz8SNbH53V5ZsvojR7f6bbAZPU7 YUf2RB3LKHB7EHIbVQ8N5A1+1fC5gA5++3Suumz+QWsIHjl6Ei0w2AS1LIC2xYhqhMyj ONcODg87ziJqqY+UD5gHbgyHAkTmgxXlLPqJI=
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:content-transfer-encoding; b=c3/TSa9qtGGShmSChqnpv+MRhhTaA8OlO7SApdKqIIP9T5vFuDGj0e+2gcJdp2CU0P Aerfdq2PpBsioF4rwhXcE+FF6SyA1gopdVjHv74mRnaZKC4g6wSNPzsHKskctOU66n7x 9Lf+PLQOY0+iD9eUPd3VvZw5akTLus6A1WfNI=
MIME-Version: 1.0
Received: by 10.204.71.4 with SMTP id f4mr674276bkj.183.1290093050150; Thu, 18 Nov 2010 07:10:50 -0800 (PST)
Received: by 10.204.122.12 with HTTP; Thu, 18 Nov 2010 07:10:50 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org>
References: <alpine.BSF.2.00.1011180553250.83352@fledge.watson.org>
Date: Thu, 18 Nov 2010 11:10:50 -0400
Message-ID: <AANLkTinTNsV=CFc10fhULMx3cpaoaYhUKiCMkFj1p3cn@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Samuel Weiler <weiler@watson.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 15:10:08 -0000

On Thu, Nov 18, 2010 at 7:02 AM, Samuel Weiler <weiler@watson.org> wrote:
> Recently CZNIC reported on some algorithm rollover problems they encountered
> when they didn't follow the "mandatory algorithm rules" in the "Zone
> Signing" section of RFC4035.  These rules create a method to signal to
> resolvers what algorithms are in use in a zone.  As historical perspective,
> these rules were written in order to avoid the dilemma of opening resolvers
> to a downgrade attack or discouraging the use of new algorithms.
>
> CZNIC published a DNSKEY for a "new" algorithm without simultaneously
> publishing the corresponding RRSIGs.  Unbound started rejecting answers from
> .cz because the zone didn't also include the new RRSIGs, even though Unbound
> fully supported the old algorithm and the RRSIGs for that old algorithm were
> present in the zone.
>
> These rules are indeed for zone operators and/or signers and do not need to
> be enforced by a validator.  While I haven't worked through the validation
> sections of 4035 closely, I think Unbound is violating the RFC by checking
> for this.  (It would fine for Unbound to disable support for the "old"
> algorithm entirely, in which case the answers should indeed be rejected, but
> that isn't what happened here.)  In contrast, BIND found the signatures from
> the "old" algorithm sufficient.
>
>
> I've heard folks from CZNIC advocating adding some clarifications to
> 4641bis and other operational documents reminding zone operators of
> these rules, perhaps in better language.  I generally support that.

What server software were they running?

The whole point of "MUST" is that compliant implementations do exactly
the "MUST" thing.

The zone operator should be aware of the rules, but the authority
server software really
should be enforcing the rules. If it doesn't, it's at least a bug, if
not an RFC violation.

The zone should not have been able to be loaded with the signatures missing.

And given that it did, I'd say unbound did everyone a favor in this
instance, highlighting both
the operational issue, and the RFC issue we're discussing here.

Brian