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

Dick Franks <> Mon, 26 June 2017 11:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA267129B17 for <>; Mon, 26 Jun 2017 04:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xXOGzVe7Kq_i for <>; Mon, 26 Jun 2017 04:30:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 043F1126CD8 for <>; Mon, 26 Jun 2017 04:30:39 -0700 (PDT)
Received: by with SMTP id c189so52661534oia.2 for <>; Mon, 26 Jun 2017 04:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xXHsgE9GxCsl07HI98OAbgZaMVj0+5O6T7yLUwoHlug=; b=TlCohsCL1GpBCsDU72gDhHoy0ndff+z2U9pMPaKm4LqOxizrI2m6v2IMqwCfJCzob2 a7tXbs2wdNgRJVzh6l87tO6tv5G2jxsWxHlAwvRi8iuvbyfobLF+ISp1ZP7YLJHZsZ/Z To5MOKudlIs5JFt6Pg/C6dVrfEujznWPN9CIJNp4nEK2on9/azsfFjoBcg4v8oEDzxRp 0rsa8FbPPCiReid4kpWBCdyXVOHor+QdgoHe2KoTnCInG01v68aP/ryHWkscpb9Zrnja OI0Nc/v1Hppcpac3oXY/o1O3Y0D6dJtubX5KkH37bJ7kSH8bvGfC466dGkc08NEl/8+f oDcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xXHsgE9GxCsl07HI98OAbgZaMVj0+5O6T7yLUwoHlug=; b=qi1qS3UyyuHFzC9+FAiuILpK3F/mbAEwTPpBY6SUOc7k9/9hbagaDUonY3yLseNawJ nT8dZHnhb86qFflkT1nza5bQpWxNxuyHhypzDGvrU4qDyvlMlagm8dWhZz8M6kNbIbAU cOaB/7Vyx3cvBIEV4czw+sFcrCEOP+3XZg/U2Tl79zxHELGhR9QqaJAqZcC4dseg3jCo FHqOWvRrx/WOf8fvRYvaH2nQS7cQnISJb5yzYLHlfkCGqZuPsjot6mxhif1cjfsV0TVg C3K3pKghXTS9hEXz6O1mSfy33gpGfOhEPVm4s6DPKnIiRBh4oxEktvxCHk/1y4rRhPAa YIeA==
X-Gm-Message-State: AKS2vOzMb5yye9IrBl1Zso7usRP9O6SQNdKK/tSNZm16ogzxw8LJlx2X QtvFSwArYn/pZxHodLeSxgi4bNXaIQ==
X-Received: by with SMTP id s76mr7472955oie.156.1498476638373; Mon, 26 Jun 2017 04:30:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Jun 2017 04:29:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Dick Franks <>
Date: Mon, 26 Jun 2017 12:29:57 +0100
X-Google-Sender-Auth: ubsv5hr_TjFvfqb9TH_ztXUDPYI
Message-ID: <>
To: Matthijs Mekking <>
Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= <>, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <>, tjw ietf <>, IETF DNSOP WG <>, Suzanne Woolf <>,,, Olafur Gudmundsson <>, RFC Editor <>
Content-Type: multipart/alternative; boundary="001a113cc044bc10d00552db4777"
Archived-At: <>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jun 2017 11:30:41 -0000

On 26 June 2017 at 09:39, Matthijs Mekking <> 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.

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.

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.