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

Dick Franks <rwfranks@acm.org> Tue, 27 June 2017 12:29 UTC

Return-Path: <rwfranks@gmail.com>
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 0F884129AD7 for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 05:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wyfmQj-yQKgO for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 05:29:21 -0700 (PDT)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F14B129AD4 for <dnsop@ietf.org>; Tue, 27 Jun 2017 05:29:21 -0700 (PDT)
Received: by mail-ot0-x22e.google.com with SMTP id r67so20718034ota.1 for <dnsop@ietf.org>; Tue, 27 Jun 2017 05:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YtcABbPZ1CtW1XW8bLf9enZxNiuEwd/xFF5KTO0y26M=; b=aCQTBXyVkog0ITz3y8HRr90W5q0gc1xwG/wKp7d79iUGEEZtaFgVoT0K/eRz+WWolL 0aw3uC7Hk05/tVp1XXfV4iir/CFW/nWgoqqq9eiUBZMsnFEcwwz1HGk3A5gsULaQYDNX PBOxmRoaxEV0pd4/K8iRjg9UmIh2OR7oGL6KhMcUNuP+Bx4IR72i4McQZQTrZqwqVaQL HEaG/lSpTUHuIzaAeHmIt4HQXX/+IqOeWzq3gmrbgs+C7XXRTlhZdJIbhEI6iivnXHW0 yDt0xPUIdc9WpaxWJToevGrInJ9kIOl3szFTHqwo6EyqMt54d/BpagZ4WiLljo1UnLG8 Q4dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YtcABbPZ1CtW1XW8bLf9enZxNiuEwd/xFF5KTO0y26M=; b=n8KLlaRrYldTTMPyL/++LSpFKF0LzU/4qAwiT+vUdQS0pkTWIpcEnM/3qrj3dSSrFp JLO8HqbeFglzfoosUOkoEzmyUWVE3UzjxIH6CZpkxdb9zzsTo3Yklw2x0Gkes6OHVjQA s92G5OAU64Jd8Auue87dPXGcJ6vcBD64Rnrs8E4727DiQ9FckyIu99xvxsSbMaeHkGi8 eH9UtT9NTHHxCbIYKGJd4AKMI0Q6pobuyXBesh21j5aJVwevhaRm/hPrUC+OYRmUlFQm fnHmd1HZy7XsJM/xMs2dPqLSLxnRv4xF5v4PyVAkql0mNHOcjh4I6rhU7eLyaH9askKv NftQ==
X-Gm-Message-State: AKS2vOysG7zjpVxfURhy35YbHpQUmsW5U8Omd5qj44dylwLys2FT+WKl O3SeEkjE3SwISDTJhzBvaqLRZ3wbzA==
X-Received: by 10.157.52.132 with SMTP id g4mr1203475otc.213.1498566560630; Tue, 27 Jun 2017 05:29:20 -0700 (PDT)
MIME-Version: 1.0
Sender: rwfranks@gmail.com
Received: by 10.182.232.163 with HTTP; Tue, 27 Jun 2017 05:28:40 -0700 (PDT)
In-Reply-To: <cfed78ae-0133-e883-f579-3a9ca92ccab0@pletterpet.nl>
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> <cfed78ae-0133-e883-f579-3a9ca92ccab0@pletterpet.nl>
From: Dick Franks <rwfranks@acm.org>
Date: Tue, 27 Jun 2017 13:28:40 +0100
X-Google-Sender-Auth: hoAOXLEqV0WkaR0MYXncZrjmvOo
Message-ID: <CAKW6Ri55OMz2ZO27XVNeEYTqscx6hJk+VqTE7p8DyV53uQ0YmA@mail.gmail.com>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: =?UTF-8?Q?Ond=C5=99ej_Caletka?= <Ondrej.Caletka@cesnet.cz>, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <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>
Content-Type: multipart/alternative; boundary="001a113ef7e484cebe0552f03742"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p4jg_noSoEuYxmrB49mrCzFQSig>
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: Tue, 27 Jun 2017 12:29:23 -0000

On 26 June 2017 at 15:30, Matthijs Mekking <matthijs@pletterpet.nl> wrote:

>
>
> On 26-06-17 13:29, Dick Franks wrote:
>
> You misunderstood: Variable length in octets, but not variable in number
> of RDATA elements


I did.

Am I correct in thinking that you want some acknowledgement that 4 fields
exist, but do not really care what the final item is?


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?
>

That is what we should be discussing, but this erratum seems to be steering
us along a road full of potholes that I certainly do not want to fall into.
IMHO this is based on a misunderstanding of your "mandated notation"
argument.



> 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.
>

I would go further, and say that all fields (except algorithm) 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.
>

The one RR requirement is not in dispute.

Let us make a start with the following 3 use cases, to see if we can come
to some common understanding of what we are trying to achieve.

(1)  CDS arrives on the wire

cds.example. IN CDS  \# 5 1234 00 56 78      ; silly numbers in most fields

RDATA as received:

         'algorithm' => 0,
         'digestbin' => 'x',
         'digtype' => 86,
         'keytag' => 4660,

Algorithm = 0, so presentation format uses "RFC8078 mandated notation":

cds.example.    IN    CDS    0 0 0 0


(2)  DELETE CDS read from zone file, transmitted to parent

cds.example.    IN    CDS    0 0 0 0

Algorithm = 0, so this is a DELETE CDS.

Check that RDATA string matches "mandated notation".

Coerce all RDATA numerical fields to zero, digest empty.

Transmitted CDS RR:

cds.example. IN CDS  \# 4 0000 00 00


(3)  Normal CDS read from zone file, but with accidental 0 in algorithm
field

cds.example. CDS 6485 0 1 2bb183af5f22588179a53b0a98631fad1a292118

Algorithm = 0, so this is apparently a DELETE CDS.

Exception raised - RDATA does not match "mandated notation"

DS saved from accidental deletion:-)


Obviously, similar logic applies to CDNSKEY.

--Dick