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

Jan Včelák <jv@fcelda.cz> Tue, 27 June 2017 17:10 UTC

Return-Path: <jv@fcelda.cz>
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 72A73129572 for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 10:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 SMuznDsG0UzO for <dnsop@ietfa.amsl.com>; Tue, 27 Jun 2017 10:10:23 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 017AE127078 for <dnsop@ietf.org>; Tue, 27 Jun 2017 10:10:22 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id w19so1591400uac.0 for <dnsop@ietf.org>; Tue, 27 Jun 2017 10:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5rDz/3opxZeOcxJwDk+rRU6lNr5f+V9qr2gAGWbMKYY=; b=QzeP+qpMxWeGgucODAoeFrllsq7GV+X8pNePDVmN7EDxA/t1Bt0E7fHGgOmIoRQCOd iPoF3NOAHD99WEr8IdVS/NiCBbjFE1Finfptd7JkYwUE14Tb/vRB0+5Fp/WAcLbhPwvN OLya0yzxJ1ERtl3HD/HhVpCsM8SYe9ZP8y+ig=
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; bh=5rDz/3opxZeOcxJwDk+rRU6lNr5f+V9qr2gAGWbMKYY=; b=FwuQ8xVliTDP6gcvwOc6E/HV3r71SlxrmMPdnUO60Fc3ynlC8ycwJNAZuKA9PHuxtJ OlWdgXkZ410USiHFtB0xSVffTFW1pYEyPaLLEzBmJ291CoS4GADJtY5DVlocCo6vaDD3 3S2ChiIyp9SOQShSctXBDNuBCON1dIScPI7VLoG0JGO0PdbCmXTogX/2IRxMX035Jn3V f7/VuCaGpQmIKXwZqzfuujHAtlH23jozaJ4lWeenKVT5uwXpjKBhomWuNLGNPZmIrql2 nJrz3yvOUCpHc1kX0rocHKJp3yWtEX1Nc4y6TahkigR/T4yZEoLOUCi3nnv5FpsamrEm PEJQ==
X-Gm-Message-State: AKS2vOwxqOHyb/S71xviUdLzmTaHYrtZlrrnvVOIiMvQQLxLW5yVLMM1 bu3YlGX09UciZiV+6D3L5UDZHY+n/H8omidhHgDB
X-Received: by 10.176.70.201 with SMTP id t9mr3158216uab.65.1498583421548; Tue, 27 Jun 2017 10:10:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.89.92 with HTTP; Tue, 27 Jun 2017 10:10:01 -0700 (PDT)
X-Originating-IP: [94.112.122.95]
In-Reply-To: <20170627145452.623CB7C84E77@rock.dv.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> <20170627145452.623CB7C84E77@rock.dv.isc.org>
From: Jan Včelák <jv@fcelda.cz>
Date: Tue, 27 Jun 2017 19:10:01 +0200
Message-ID: <CAM1xaJ8UniCt+8CnO70_6GM9e6TvyN-0BVC69MRmaXcM78kviQ@mail.gmail.com>
To: IETF DNSOP WG <dnsop@ietf.org>
Cc: Mark Andrews <marka@isc.org>, Dick Franks <rwfranks@acm.org>, tjw ietf <tjw.ietf@gmail.com>, Matthijs Mekking <matthijs@pletterpet.nl>, Ondřej Caletka <Ondrej.Caletka@cesnet.cz>, Ólafur Guðmundsson <olafur@cloudflare.com>, 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: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nT2nC8zlqcoB0y4Ivm1PWE6CO6o>
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 17:10:26 -0000

I'm not sure if this discussion is moving forward.

CDS/CDNSKEY RDATA format is the same as DS/DNSKEY RDATA format per
definition in Section 3 of RFC 7344. Although DS Digest field and
DNSKEY Public Key field can be zero-length on wire, the presentation
format is underspecified and it practically cannot be used in this
case. That is a problem in implementations where presentation format
is used (e.g. in zone file). And we have already confirmed existence
of this problem in some implementations in this very thread.

This erratum makes a simple change that as a result gives one clear
interpretation of how the DS DELETE request should look like. And it
allows CDS/CDNSKEY record for the request to be specified both in wire
and presentation format.

There is plenty other alternative ways to express DS DELETE request.
But I would prefer accepting this simple erratum rather than
researching all the other options (which we should have done when
revising the drafts of this document).

Jan


On Tue, Jun 27, 2017 at 4:54 PM, Mark Andrews <marka@isc.org> wrote:
>
> 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>, 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop