Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09
Donald Eastlake <d3e3e3@gmail.com> Mon, 21 September 2020 20:35 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F040E3A0936; Mon, 21 Sep 2020 13:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Gv4JwIImmocv; Mon, 21 Sep 2020 13:35:56 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 5E59F3A0930; Mon, 21 Sep 2020 13:35:56 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id z13so16986423iom.8; Mon, 21 Sep 2020 13:35:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ycaqGEnhg2Edhxtx4xozB/8lBpkU2A2cM2JvtoIQss=; b=lpK696MTeOSTgorFtFH1FEOmnRDZw/QYOr3Zp6ME9XfYspj4zJ6wHok5dqUIFhmYq2 q5kHk44e52DLTYk10xE7TXgKOBAX4ClfNKkBLe2ACWKtbIxq5GEwkioiR8kOzRPfC5Xw kFNkF3aLhyrskI+ksZjbLqd1SQSyf9DpiTBVvVbGcZ8fTvnYBVgGFkvH2FLfsF5BC+5c mRrG7nDkyAVpCBg6GsSM1a/D5RmbDeL/0UYP9WoUu7nWgTh7ODHGlvX6a0jt2JErIaBS ukHuXnheuGXhtMQ917tjhW2omOaJDAIb65J88in7rsMLwrNuPNGphsH9R3KdjMtKGbUZ egFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ycaqGEnhg2Edhxtx4xozB/8lBpkU2A2cM2JvtoIQss=; b=XAK+SAma8sq0985uz4W3P0phmSgaZ8Q3fFkcHMyxUXbZTHSLXo2NH7vUzyaEUUpRyr z2HanaiiVpil73It3S3Z2j+H8ki74DBvtbJcDGn/wb9+2UZetm78G8BfTRI6iXEcnsZb ZxSscV3G/hujzz+DfWe+qrTTQAEBV2WGPl8IUwSpI+eL67Bm0tkEVAiJ4cJPqIJBGW8Y VpLIotCiQDdAIuRgMclJXh391PfqoEpkzuXVs67lzPswXYJPSp1Qsmnl3xNXJ9/a7CQH b6aADEgPHo8jC5w10uUJ3ZcxXMc1wzGmQx/VDNbilxwqjp51kD5OzmqTGxoAqGkQNd75 7EgA==
X-Gm-Message-State: AOAM532JFIRlMQoq8yRK29dti7aSijKcSEAmCGQqOdhNEO+iCmkW0BUS SNGKFTLlRQnzgfj7qkCIIF8/k3xHI/MkUIJLhUaG87t4Ebw=
X-Google-Smtp-Source: ABdhPJxGuU9DoZJ4NWSNcM1gA/DRBrmZA3kYU0wQdOmzBhaYPp0017YyYd5AH8qx0zSqI3mxQo+22dI8nk0X8k+XdiA=
X-Received: by 2002:a6b:2c44:: with SMTP id s65mr922946ios.185.1600720555041; Mon, 21 Sep 2020 13:35:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAF4+nEGaCJ0Y+_Q9Q+HbbBWCcOgzH-rLG+OoP5d-LxXtmCYqNQ@mail.gmail.com> <CAF4+nEHXrK1Got=CsfhpW_v8Z3i3dZKsRXUABiGcfHWzQ01yQQ@mail.gmail.com> <D0617842-4E1A-43A1-9933-9C8737B4F4F4@verisign.com> <CAF4+nEGtAFnxQvBNpqBOY7Hd0ottn5E9_p=kBbS8VEMpRzx1-Q@mail.gmail.com> <D2C49B4C-8C93-4FBA-BE94-6EFBA83BBBED@verisign.com>
In-Reply-To: <D2C49B4C-8C93-4FBA-BE94-6EFBA83BBBED@verisign.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 21 Sep 2020 16:35:43 -0400
Message-ID: <CAF4+nEHUKxS=MeVADrck40XH8f3ARSa+DNpPZA4OSKq6iiaMzg@mail.gmail.com>
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dnsop-dns-zone-digest.all@ietf.org" <draft-ietf-dnsop-dns-zone-digest.all@ietf.org>, secdir <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011680e05afd8cc3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/H-aL5Xbug4iODo77qa1HaWgFlUw>
Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 20:35:59 -0000
Hi Duane, Thanks, looks good to me. I'll check the draft when it comes out. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Sep 21, 2020 at 1:31 PM Wessels, Duane <dwessels@verisign.com> wrote: > Donald, > > Thanks again for this draft review and feedback. After discussions among > the coauthors we have made the further changes that you suggest. Namely: > > - minimum digest length of 12 octets > - added SHA512 as algorithm 2 > - local policy allows some schemes / algorithms to be ignored > - implementation status moved to an appendix > > I think there are no more outstanding issues. I will be posting an > updated revision of the draft shortly. > > DW > > > > On Sep 15, 2020, at 7:34 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: > > > > Hi Duane, > > > > Thanks for accepting most of my suggestions. > > > > See my responses below at <de> on the items we are still discussing. > > > > On Tue, Sep 15, 2020 at 11:38 AM Wessels, Duane <dwessels@verisign.com> > wrote: > > Thanks Don for the extensive review! tl;dr, we did accept most/many of > your suggestions already, except these items may warrant further discussion: > > > > - minimum digest length > > - more hash algorithms than SHA-384 > > - local policy when verifying multiple digests > > - implementation status section > > > > More responses inline below. > > > > DW > > > > > On Sep 12, 2020, at 6:53 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: > > > > > ... > > > > > > 2) The minimum size of the Digest Field, 1 octet, seems too small. > > > Typical minimum size for such a field in IETF protocols seems to be 96 > > > bits or 12 octets, so that, at least with a strong hash function, you > > > have a reasonable resistance against brute force attacks. Also, while > > > it is fairly obvious, you might want to mention how a receiver > > > determines the length of the Digest Field. > > > > > > OLD (Section 2.2.4) > > > The Digest field must not be empty. > > > > > > NEW > > > The Digest Field MUST NOT be shorter than 12 octets. If it is, the > > > ZONEMD RR containing that short digest cannot be used to verify a > > > zone. The length of the digest field is determined by deducting the > > > fixed size of the Serial, Scheme, and Hash Algorithm fields from the > > > RDATA size in the ZONEMD RR header. > > > > I'm not necessarily opposed to a minimum digest size. Do you envision > > any complications with private use algorithms though? It seems a little > > strange to allow private use algorithms whose digest value could be > anything, > > but requiring a minimum size (which could then simply be padded I know). > > > > <de> Well, it looked to me like the draft already had a minimum Digest > field, namely one octet, since it said the Digest Field couldn't be empty. > As I recall, the digest didn't say what to do if the Digest field was zero > length but I presume it would mean that the ZONEMD RR was malformed and > thus could not be used to validate a zone. Seems like the minimum length > would apply to private use algorithms also. See Section 5.2.2.1 of > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09 > > > > > 3) SHA384 / algorithm agility > > > -- here are some thoughts/comments on SHA384 and algorithm agility: > > ... > > > > > > 3c) SHA2-384 is just SHA2-512 with some different initialization > > > values and with the 512 bit output truncated to 384. Thus the > > > incremental effort of providing SHA2-512 in tiny if you have SHA2-384 > > > (and vice versa). So, if SHA2-384 is mandatory, then you might as well > > > make SHA2-512 mandatory also since you get it for probably <1% > > > incremental effort. Having two mandatory algorithms with some people > > > using one and some the other would provide some real confidence that > > > implementations were actually looking at the Hash Algorithm Field, > > > could handle Digest Fields of different length, etc., and the > > > algorithm agility mechanisms might actually work. It currently looks a > > > bit like only lip service is being paid to algorithm agility. > > > > In an earlier version of the draft, four algorithms were defined, > although > > none "past" SHA-384. There was a (Oct 2018) discussion to make SHA-384 > > the mandatory algorithm and drop all the weaker ones. > > > > I'm not necessarily opposed to adding more mandatory-to-implement > algorithms > > if there is working group consensus about that, but it feels like a > pretty > > significant and late change? > > > > <de> I agree it is a significant change in the draft. But, as I say, if > you have SHA-384 you have 99+% of the crypto code you need for SHA-384 and > SHA-512. Of course, SHA-512 has an even longer value, 64 bytes, but with > just one or at most a few ZONEMD RRs at the zone apex, that does not seem > to be a problem. Of my security comments, I rate adding a 2nd hash > algorithm as the most important. It could be that the 2nd algorithm would > be a SHOULD rather than a MUST. And, if a second algorithm is added, I > think SHA-512 would be the easiest for implementers. > > > > > 3d) On algorithm agility generally: There is a reasonable provision in > > > the ZONEMD RR for a hash algorithm identifier. But, given that this > > > is Standards Track I would have expected there to be hash algorithms > > > specified of different types with one a MUST implement and one a > > > SHOULD implement -- possible more but at least that. Blake or SHA3 > > > would be example of a different algorithm type from SHA2. But I admit > > > that SHA2-384/512 is very strong and a break in it significant enough > > > to make much difference seems very unlikely. > > > > Same as above. > > > > <de> Response above. > > > > > 4) There is no mention of local policy. If at some point there are > > > multiple hash algorithms and/or schemes specified (which could include > > > private use algorithms and schemes), a ZONEMD zone validator would > > > likely need a local policy as to which algorithm/scheme digest it will > > > pay attention to. See, for example, the first paragraph of Section 4 > > > which assumes any good digest should be good enough to validate the > > > zone for any verifier. > > > > The draft-ietf-dnsop-dns-zone-digest-00 version did have the following > text that spoke to this: > > > > > It is RECOMMENDED that implementations maintain a (possibly > > > configurable) list of supported Digest Type algorithms ranked from > > > most to least preferred. It is further RECOMMENDED that recipients > > > use only their most preferred algorithm that is present in the zone > > > for digest verification. > > > > > > As a matter of local policy, the recipient MAY require that all > > > supported and present Digest Type algorithms verify the zone. > > > > There was a thread on DNSOP where we had agreement to > > take those two paragraphs out: > > > > https://mailarchive.ietf.org/arch/msg/dnsop/RFCklH7Lx00bL-tOVRCAc0j5ftw/ > > > > <de> I went and read that thread. I agree that the text removed was kind > of complex. I was just worried that the text in Section 4 too strongly > implied that an implementation must accept a zone if a ZONEMD validates. > True, it does have text about "supporting" the Scheme and Hash Algorithm > but conceivable you could support a Scheme and a Hash Algorithm but have a > policy against accepting a ZONEMD RR that combined them and in any case I > suspect the draft is using "supported" in the sense of "implemented". I'd > be happy with adding just one sentence in Section 4 something like "The > verifier MAY ignore a ZONEMD if the Scheme and Hash Algorithm violates > local policy." > > ... > > > 6e. Actually, 240-254 seems like a lot of values for Private Use. Why > > > would you need 15 private hash algorithms within one administrative > > > area? If you think there are going to be lots of private/proprietary > > > hashes (national vanity crypto?) that get used moderately widely, > > > there should be a provision for "vendor specific" hash algorithms > > > where the "Digest Field" actually starts with a "vendor" identifier. > > > > It seemed a reasonable amount to us, but if others think it should be > > smaller that shouldn't be a problem. > > > > <de> OK. It isn't gigantic or anything, just a bit larger than the 3 or > 4 or so values I typically see. > > > > ... > > > 12. Having an Implementation Status section (Section 10) is good while > > > a draft is going through the approval process, but I think it is, as > > > indicated in RFC 7942, inappropriate in a resulting standards track > > > RFC. Furthermore, all of the disclaimer text given in RFC 7942 is > > > missing here. So, I believe similar disclaimer text should be added > > > and the RFC Editor should be requested to drop this section before > > > publication. > > > > The authors feel it could be useful, even though it is expected to > > become out-of-date. Looks like some other published RFCs have kept > > their Implementation Status sections, sometimes as an appendix? > > > > <de> OK... I think that if retained it would be much better as an > appendix. > > > > ... > > > ATTACHMENT > > > > > > Taking into account the above and to make other editorial suggestions, > > > I have done an editing pass over the draft the results of which are > > > attached. I hope you find it helpful. > > > > Thank you, we did find it very helpful. > > > > <de> You're welcome. > > > > <de> Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > d3e3e3@gmail.com > >
- [secdir] SECDIR review of draft-ietf-dnsop-dns-zo… Donald Eastlake
- [secdir] Fwd: SECDIR review of draft-ietf-dnsop-d… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Wessels, Duane
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Wessels, Duane
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Benjamin Kaduk
- Re: [secdir] SECDIR review of draft-ietf-dnsop-dn… Donald Eastlake