IETF Logo Mail Archive

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5273)

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 05 March 2018 08:39 UTC

Return-Path: <matthijs@pletterpet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB60127023 for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 00:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pNNPfW7SOEJo for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 00:39:53 -0800 (PST)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4626126579 for <dnsop@ietf.org>; Mon, 5 Mar 2018 00:39:52 -0800 (PST)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w258bcnX172597; Mon, 5 Mar 2018 08:39:47 GMT
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2gh1peg5xj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Mar 2018 08:39:46 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w258dk0C010236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Mar 2018 08:39:46 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w258deJd009308; Mon, 5 Mar 2018 08:39:43 GMT
Received: from [172.19.129.46] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Mar 2018 00:39:40 -0800
To: RFC Errata System <rfc-editor@rfc-editor.org>, bclaise@cisco.com, warren@kumari.net, suzworldwide@gmail.com, tjw.ietf@gmail.com
Cc: dnsop@ietf.org, rfceditor@centroid.eu
References: <20180303140335.59022B80C97@rfc-editor.org>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <fa215576-b631-eaf4-c888-e20eb85b0db3@pletterpet.nl>
Date: Mon, 05 Mar 2018 09:39:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180303140335.59022B80C97@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8822 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050102
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kum5HrccU6b5RADvkt6OIB8NXdY>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC6781 (5273)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 08:39:55 -0000

All,

I think this errata is incorrect: For an algorithm rollover it is 
intended that at the "DNSKEY removal" step, the DNSKEYs are removed from 
the zone, but the signatures stay. This is to play nicely with 
conservative validators:

    The conservative approach interprets this section very strictly,
    meaning that it expects that every RRset has a valid signature for
    every algorithm signaled by the zone apex DNSKEY RRset, including
    RRsets in caches.

However, looking into this errata I do think there is an error in Figure 
8 in section 4.1.4:

The figure should have the signature of the old KSK, called 
RRSIG_K_1(DNSKEY) in the "DNSKEY removal" step.

Because a conservative validator may have the DNSKEY RRset cached that 
includes DNSKEY_K_1, DNSKEY_K_2, DNSKEY_Z_1, and DNSKEY_Z_2.


Regarding the notes on this errata:

 > because:  I just don't think you can sign a zone without the
 > corresponding ZSK's.

It is certainly possible to sign zones and not publish the corresponding 
DNSKEY.

Best regards,
   Matthijs


On 03-03-18 15:03, RFC Errata System wrote:
> The following errata report has been submitted for RFC6781,
> "DNSSEC Operational Practices, Version 2".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5273
> 
> --------------------------------------
> Type: Technical
> Reported by: Peter J. Philipp <rfceditor@centroid.eu>
> 
> Section: 4.1.4
> 
> Original Text
> -------------
> Figure 8 on page 30.
> 
> Corrected Text
> --------------
> The figure should have the second ZSK DNSKEY, called DNSKEY_Z_10 under
> DNSKEY removal because SOA_3 is doubly signed.
> 
> or
> 
> The figure should not have the second RRSIG for SOA_3 that is derived
> from DNSKEY_Z_10.
> 
> because:  I just don't think you can sign a zone without the
> corresponding ZSK's.



> 
> 
> Notes
> -----
> It looks wrong to me.  A small technicality.  I'll let the authors decide if it's really wrong.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
> --------------------------------------
> Title               : DNSSEC Operational Practices, Version 2
> Publication Date    : December 2012
> Author(s)           : O. Kolkman, W. Mekking, R. Gieben
> Category            : INFORMATIONAL
> Source              : Domain Name System Operations
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email