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

Mark Andrews <marka@isc.org> Tue, 27 June 2017 14:55 UTC

Return-Path: <marka@isc.org>
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 21810129B41 for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 07:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 dvpnijRvWUHg for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 07:55:06 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 2077B129B1A for <dnsop@ietf.org>; Tue, 27 Jun 2017 07:55:06 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 37FE624AE08; Tue, 27 Jun 2017 14:54:53 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 75785160048; Tue, 27 Jun 2017 14:54:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2E7F5160096; Tue, 27 Jun 2017 14:54:56 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8TS-unkozhl1; Tue, 27 Jun 2017 14:54:56 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 89C3C160048; Tue, 27 Jun 2017 14:54:55 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 623CB7C84E77; Wed, 28 Jun 2017 00:54:52 +1000 (AEST)
To: Dick Franks <rwfranks@acm.org>
Cc: Matthijs Mekking <matthijs@pletterpet.nl>, tjw ietf <tjw.ietf@gmail.com>, =?UTF-8?Q?Ond=C5=99ej_Caletka?= <Ondrej.Caletka@cesnet.cz>, =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>, Suzanne Woolf <suzworldwide@gmail.com>, pwouters@redhat.com, bclaise@cisco.com, IETF DNSOP WG <dnsop@ietf.org>, Olafur Gudmundsson <olafur+ietf@cloudflare.com>, RFC Editor <rfc-editor@rfc-editor.org>
From: Mark Andrews <marka@isc.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> <cfed78ae-0133-e883-f579-3a9ca92ccab0@pletterpet.nl> <CAKW6Ri55OMz2ZO27XVNeEYTqscx6hJk+VqTE7p8DyV53uQ0YmA@mail.gmail.com>
In-reply-to: Your message of "Tue, 27 Jun 2017 13:28:40 +0100." <CAKW6Ri55OMz2ZO27XVNeEYTqscx6hJk+VqTE7p8DyV53uQ0YmA@mail.gmail.com>
Date: Wed, 28 Jun 2017 00:54:52 +1000
Message-Id: <20170627145452.623CB7C84E77@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/M_NLf2t1tINaMNVNAQLdIN64OTw>
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 14:55:08 -0000

And in reality it will be something like for CDS:

if (validated && rrset_count == 1 &&
    rdata->len >= 4 && !memcmp(rdata->data, "\0\0\0", 4))
	remove_ds();

because this will all be done in wire format.  Note the above ignores
the hash content for the CDS if any.  The problem is that we do not
have a well defined wire format for this signal.

"The keying material payload is represented by a single 0."  The
quoted sentence does not make sense.  I can think of 3 interpretions
of that sentence.

1.  the zero is a place holder for zero length field.
2.  the field is a zero byte.
3.  the field can be any non zero length content but we
    are showing it as a zero as it is to be ignored.

Remember this record has to be written out and read back in by slave
servers across restarts.  They MUST *all* produce the same wire
representation or else the returned rrset will not validate.

Mark

In message <CAKW6Ri55OMz2ZO27XVNeEYTqscx6hJk+VqTE7p8DyV53uQ0YmA@mail.gmail.com>om>, Dick Franks wr
ites:
> 
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org