Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Matthijs Mekking <matthijs@pletterpet.nl> Mon, 26 June 2017 14:30 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 2889912EAA1 for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 07:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Fxo8vLesDg-9 for <dnsop@ietfa.amsl.com>; Mon, 26 Jun 2017 07:30:56 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3CAEF12EAAB for <dnsop@ietf.org>; Mon, 26 Jun 2017 07:30:55 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v5QEUgTf021261 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jun 2017 14:30:42 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v5QEUegl027638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jun 2017 14:30:42 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v5QEUbUU020190; Mon, 26 Jun 2017 14:30:38 GMT
Received: from [172.19.130.10] (/216.146.45.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jun 2017 07:30:37 -0700
To: Dick Franks <rwfranks@acm.org>
Cc: Ondřej Caletka <Ondrej.Caletka@cesnet.cz>, Ólafur Guðmundsson <olafur@cloudflare.com>, tjw ietf <tjw.ietf@gmail.com>, IETF DNSOP WG <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>, pwouters@redhat.com, bclaise@cisco.com, Olafur Gudmundsson <olafur+ietf@cloudflare.com>, RFC Editor <rfc-editor@rfc-editor.org>
References: <20170623105434.22478B810AB@rfc-editor.org> <CAN6NTqyBg74NF-F8imGiK0ArwxAbhc0uE_xXbX-No+Le8E9DUg@mail.gmail.com> <CAKW6Ri7npS57gupPrUc2aGhsg21u8csx+69GKrCFkeQ6H5Dnxw@mail.gmail.com> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <CAKW6Ri5hsUEFuWmVp1UNauk=C7HykdiA9stQoMcdDs6gd6+axg@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <cfed78ae-0133-e883-f579-3a9ca92ccab0@pletterpet.nl>
Date: Mon, 26 Jun 2017 16:30:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAKW6Ri5hsUEFuWmVp1UNauk=C7HykdiA9stQoMcdDs6gd6+axg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GANa1OaW0gPmnYboRMZh4t3lkqU>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
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, 26 Jun 2017 14:30:58 -0000


On 26-06-17 13:29, Dick Franks wrote:
> 
> On 26 June 2017 at 09:39, Matthijs Mekking <matthijs@pletterpet.nl 
> <mailto:matthijs@pletterpet.nl>> wrote:
> 
>     I raised the specific issue because the to be RFC 8078 was going to
>     change the CDS and CDNSKEY RDATA format from a fixed length RDATA to
>     a variable length: In case of the DELETE operation, the Digest in
>     presentation format was omitted.
> 
> 
> CDS and CDNSKEY are both variable length. There is no length component 
> in the RDATA itself. The length of the digest (or key) is calculated 
> (RDLENGTH - 4) so whether there is one byte or none at all makes not a 
> scrap of difference. So that explanation can be dismissed immediately.

You misunderstood: Variable length in octets, but not variable in number 
of RDATA elements.

>     While I agree with Paul in that thread that we should use all zeros
>     for the DELETE operation, I believe it was an oversight that the
>     proper encodings (hexadecimal, base64) should be used.
> 
> 
> Not just an oversight. Now it is an oversight baked into an IESG 
> approved standards track document.
> 
> So an implementer has little choice but to make CDS/CDNSKEY work in 
> accordance with the standard as written until IESG approves something else.

Sure, but that is why we are discussing it, not?

> And when that something else arrives, users will be mightily upset if 
> RFC8078 CDS/CDNSKEY suddenly stops working, so the code will need to 
> cope with both versions.  The only realistic way to achieve that is to 
> determine the entire content of the DELETE CDS/CDNSKEY from the zero 
> algorithm field. Beyond that, the content of the "mandated notation" is 
> irrelevant because it can be left unparsed.

My first suggestion for the draft was indeed: In case the DNSSEC 
algorithm is 0, the Digest/Public Key MUST be ignored.

But there were concerns that if someone mistyped the algorithm field the 
DS accidentally gets removed. So now the RFC says that the contents of 
the CDS or CDNSKEY RRset MUST contain one RR and the "0 [0,3] 0 0" 
notation is mandated.

Best regards,
   Matthijs