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

Warren Kumari <warren@kumari.net> Fri, 04 August 2017 19:55 UTC

Return-Path: <warren@kumari.net>
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 9917E126BF3 for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 12:55:13 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 8h4s0zj7LEJ9 for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 12:55:11 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 A065C131EB6 for <dnsop@ietf.org>; Fri, 4 Aug 2017 12:55:11 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id w45so11461051uac.5 for <dnsop@ietf.org>; Fri, 04 Aug 2017 12:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HheDTDnrE02HLJUxRo85Sz9W2jw+K4UVuDFWGJsQijI=; b=XOyqVwRJoFhLx/z1LyrmsaXFZkAQR5SqLiV6s+UwxV9w7aZT24wWc3IJKVDwl/TfEd i1M0PiO90BRyDE7DE4aCm4MFLdCdtXUCb/ylYfxh0PUY1YzW6N38rBimH66R7k9116BX 6bzpVJyrwXpEapsYWHH2RmlgAItkbLV9fWhVdZdFILem/EvLwTQWwfvyZHMoBDPVQ2hD EzNbjXrg//Tn2EPOXaTwaBAbrNE3ajw7BJ5OYfiTdkhOx8tu7EBjQQ0+Echmr9iDyldW LcheQga6bKfO7hBsb/yFN5deJXtEDLes3s+Y0ZSUOMV4IFGF1QP+zlfz+E5gSoLmLuiW V3iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HheDTDnrE02HLJUxRo85Sz9W2jw+K4UVuDFWGJsQijI=; b=Vpbbv3KqhFAA5bFho7vRXCW+DSbcxflneU3YwBXgIdOj9GMDYk7pRyUxfh37dwnhTW k06f6/mLL9Qmt7n+Z6o0Ne8O/f5Pz1fbiUQXtS70bVArBSdCanRB+8XIQWEkqc77Ccsi gToInp/KJxOxg1zxLnNlrrphMWs4kTumse5Ga/pwmJzQlq7SQoDdpvqsXPbj4eW4sQB+ S/aM3KBJB7imuMaqnoFc9PiyifNtIHTNx6KVUzimm5LFhCQu4gRmVMNQB3KbhOKj3LBd qpdULwRyqUm1Qembn70yLwEMIj1ZT15byx8PldWG1cEk8xqNjUY9DzqSi9eY6Zf4gAvl dFfw==
X-Gm-Message-State: AHYfb5hseKbhrTxBb/1svWEsBV/KzLlEiRKgom4iLwU6RRpGxs40H/AJ fEMWzb9d1Dg856P9xhZuT+tlZ8ZSwEsM
X-Received: by 10.176.18.71 with SMTP id s7mr2607871uac.127.1501876510627; Fri, 04 Aug 2017 12:55:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.9.231 with HTTP; Fri, 4 Aug 2017 12:54:30 -0700 (PDT)
In-Reply-To: <6e0e2e92-6c06-38cf-16d9-a78ddfbaaed6@cesnet.cz>
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> <CAKW6Ri55OMz2ZO27XVNeEYTqscx6hJk+VqTE7p8DyV53uQ0YmA@mail.gmail.com> <20170627145452.623CB7C84E77@rock.dv.isc.org> <CAM1xaJ8UniCt+8CnO70_6GM9e6TvyN-0BVC69MRmaXcM78kviQ@mail.gmail.com> <CAKW6Ri6jCkm09UoJCoBe6c9jMsMjO4OihnCtzSmewnXQXv4qdw@mail.gmail.com> <20170628042127.863D87CA0CFF@rock.dv.isc.org> <6e0e2e92-6c06-38cf-16d9-a78ddfbaaed6@cesnet.cz>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 04 Aug 2017 15:54:30 -0400
Message-ID: <CAHw9_iKn3bumJ3xk8rB291zUOOvbn_RTTVAMyNJz85iPuH6Gng@mail.gmail.com>
To: Ondřej Caletka <Ondrej.Caletka@cesnet.cz>
Cc: Mark Andrews <marka@isc.org>, Dick Franks <rwfranks@acm.org>, tjw ietf <tjw.ietf@gmail.com>, Matthijs Mekking <matthijs@pletterpet.nl>, Jan Včelák <jv@fcelda.cz>, Jaromír Talíř <jaromir.talir@nic.cz>, IETF DNSOP WG <dnsop@ietf.org>, Suzanne Woolf <suzworldwide@gmail.com>, Paul Wouters <pwouters@redhat.com>, Benoit Claise <bclaise@cisco.com>, Ólafur Guðmundsson <olafur@cloudflare.com>, Olafur Gudmundsson <olafur+ietf@cloudflare.com>, RFC Editor <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jeovrDDcrKyPKsS9Xe3LshgweCU>
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: Fri, 04 Aug 2017 19:55:14 -0000

Hi all,

I gave this discussion some time to converge[0], and also asked for
more comments during the (2nd) DNSOP session in Prague.

Unless I hear strong objections by Wednesday I'll mark the errata as
verified (with the minor clarification provided):
Strictly speaking, the CDS record could be "CDS X 0 X X" as only the
DNSKEY algorithm is what signals the DELETE operation, but for
clarity, the "0 0 0 00" notation is mandated -- this is not a
definition of DS digest algorithm 0.  The same argument applies to
"CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by
[RFC4034], Section 2.1.2.


W
[0]: Yeah, that sounds much better than "procrastinated" :-)


On Wed, Jun 28, 2017 at 7:27 AM, Ondřej Caletka
<Ondrej.Caletka@cesnet.cz> wrote:
> Hello,
>
>>Dick Franks:
>>> What is needed now is methodical use-case analysis based on RFC8078 as it
>>> exists now and tested against a real implementation.  The time to rewrite
>>> the RFC will come if/when we discover we are unable to live with it. We
>>> have not reached that point yet.
> Mark Andrews:
>> I can't go from RFC8078 to a working implementation because the
>> existing description is not clear enough to do it.  I don't think
>> anyone can do it.
>>
>> With the proposed errata fix I could write code.  For CDS the RRset
>> is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00.  For CDNSKEY
>> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.
>
> I have a confirmation from the real implementation of RFC8078 in the .CZ
> domain registry (cc jaromir.talir) that their understanding of CDNSKEY
> DELETE operation is exactly the set of RDATA quoted by Mark Andrews,
> which translates to the presentation form CDNSKEY 0 3 0 AA==
>
> I don't think there is a big room to interpret RFC 8078 differently,
> since it does not define any new presentation/wire format for
> CDS/CDNSKEY record. Therefore, even future versions of software that
> (de-)serializes RRs between wire and presentation format will have
> issues if there are not all fields mandated by RFC 4034 present in the
> rdata.
>
> --
> Ondřej Caletka
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf