Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191)

Matthijs Mekking <mmekking@dyn.com> Wed, 03 December 2014 17:40 UTC

Return-Path: <mmekking@dyn.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9A1A8AAA for <dnsext@ietfa.amsl.com>; Wed, 3 Dec 2014 09:40:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkRtZqFuuHz0 for <dnsext@ietfa.amsl.com>; Wed, 3 Dec 2014 09:40:37 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F15E1A8AAC for <dnsext@ietf.org>; Wed, 3 Dec 2014 09:40:32 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id b13so20516039wgh.3 for <dnsext@ietf.org>; Wed, 03 Dec 2014 09:40:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2IT34yqkFCfHKjkOk61i38soiTjCiptH+l1Y2tqI7V8=; b=bsgqH6P/LJfBrcrm8pc5Kt7RHsE177b8P8un4m+hNgmyTnsm8r5lwO9QFnw6a3xMGj Obn0hjzSFsYLKFcvodYlO7HDMftRvGU9rJYYzbL+m1Ix49GT2ahaqfp74P5yn+8pGEPT EJErUPzWknI/VNwyyrTDhZIkh8XhVJfuKpXyM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2IT34yqkFCfHKjkOk61i38soiTjCiptH+l1Y2tqI7V8=; b=IqmBlEl1ski49rVfSOddCH/0DjEQXFlBcMGhKFbvZIUxngbLYhVF68rVQ7ZwDvVLns /yMcc3KPjU/2vBw7TzhDrudYgFZK6WuQeB8Lz4n14Yk5IN5qtZZJ4Nb0W6veJimJfRjs dI7vPNklosnSPymZWbrAFZYEbtFFsqFgnmV+po6o87EsFuLj0rqL5gnA+3XGDfrtq/Ls zsQKavreQRp5iyT5w1tCmS5T+pgJz7odxHnLf3spCcZVL6Mos5yfONHTfeCFyvKC+9UG 54uf8lLg03RHlYvkgcyOloWlmDBnsKvh2gL73tn/aH+aHhV1KwRC55rElkWdVycV5c0j AMfg==
X-Gm-Message-State: ALoCoQkck+xYc4HJmEgXhlDjacBuq+eT5xRfuUh4fO9Y8jDwWUyCPFGY6qJE37YNbgNqivLbm/ng
X-Received: by 10.194.249.232 with SMTP id yx8mr9417369wjc.1.1417628431050; Wed, 03 Dec 2014 09:40:31 -0800 (PST)
Received: from ?IPv6:2001:981:19be:1:160:7d97:db8e:511e? ([2001:981:19be:1:160:7d97:db8e:511e]) by mx.google.com with ESMTPSA id qg11sm31153657wic.17.2014.12.03.09.40.30 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2014 09:40:30 -0800 (PST)
Message-ID: <547F4B0E.9000608@dyn.com>
Date: Wed, 03 Dec 2014 18:40:30 +0100
From: Matthijs Mekking <mmekking@dyn.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>, Jelte Jansen <jelte.jansen@sidn.nl>
References: <20141202163646.E4BFC18123F@rfc-editor.org> <547E1F3F.5040400@innovationslab.net> <547ECF19.5020006@sidn.nl> <A29D5D72-1821-4E7C-BFA4-FFE84FACF6B1@vpnc.org>
In-Reply-To: <A29D5D72-1821-4E7C-BFA4-FFE84FACF6B1@vpnc.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ObwaTRuWyP2TyWNUTqk9VexWuRU
Cc: Brian Haberman <brian@innovationslab.net>, DNSEXT Group Working <dnsext@ietf.org>
Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 03 Dec 2014 17:40:40 -0000

On 03-12-14 17:37, Paul Hoffman wrote:
> On Dec 3, 2014, at 12:51 AM, Jelte Jansen <jelte.jansen@sidn.nl>
> wrote:
>> I see a few pros and cons; yes the proposed text is correct and
>> better than the original. However, this is not the only place that
>> 'signing the zone' is used, and used with the meaning 'signing each
>> authoritative RRset within the zone' in the set of RFC4033-4035
>> (and possibly outside of those as well).
>> 
>> But I have had people ask me what 'signing the zone' actually
>> means, usually in the context of KSK vs ZSK (and hence, is the
>> DNSKEY set part of 'the zone'), not necesarily in the context of
>> algorithm downgrade protection.
>> 
>> Then again, RFC4033 actually defines a 'signed zone' as 'A zone
>> whose RRsets are signed and ...'. So while signing full zones in
>> AXFRs might add confusion here, I do think it is stated correctly
>> as it is.
> 
> Just to drive the point home a bit further, since you brought up the
> definition in RFC 4033:
> 
> Signed Zone: A zone whose RRsets are signed and that contains 
> properly constructed DNSKEY, Resource Record Signature (RRSIG), Next
> Secure (NSEC), and (optionally) DS records.
> 
> A developer asked me a few years ago "does that mean that all the
> RRsets are signed? What if just the A records are signed?" That's a
> valid question given the definition. It is only by reading the rest
> of the document do you get the feeling (but never the actual
> statement) that it means *all* of the RRsets in the zone.

It actually means all *authoritative* RRsets are signed. Glue and
occluded data for example are not signed.

The devil is in the details :)

- Matthijs


> 
> --Paul Hoffman _______________________________________________ dnsext
> mailing list dnsext@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsext
>