Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09
Donald Eastlake <d3e3e3@gmail.com> Wed, 16 September 2020 02: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 D14B33A0CCB; Tue, 15 Sep 2020 19:35:10 -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 A5PfMGuMJWZx; Tue, 15 Sep 2020 19:35:08 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 4967D3A0CCA; Tue, 15 Sep 2020 19:34:53 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id f82so5009599ilh.8; Tue, 15 Sep 2020 19:34:53 -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=rCXuHDiMKIqNJIUZmZAIEB4qMGKTDTsjBwY+QjpyxYw=; b=Evaxk8OGg8L6QSgWCuXJJ6zoJKm1nUqHxNioE3w79KZ42RwcFDwCUuNTDeZcm3RjCt RmvJ3CJvBrx7aAXXpX2Qp44EREirheHd4YV8DnvWYNMZGFdnxltgHn5BddEH1nzkcBxb N7Xd3IZQpbAR6RHAlkYP4IWuQe8g5w4U9JWPGi8+/jL/tgRdNI+QN5BerlB8H84/M9si GfkUo4ft8eUU4g2ae0vYhYm7Cocz+dHSUf+2mC+LVZsVQuqeB3IIavh9mMtHkWaYz84O nobIjBOGhFNzN0IQGzpXRAhtbwDnlKbKvB3zUleHY2/lpebzO083WBG7ETtGyuqGHXmK u9XA==
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=rCXuHDiMKIqNJIUZmZAIEB4qMGKTDTsjBwY+QjpyxYw=; b=XuqToHoN1G3AQ3wgpWXHBBdq2AQlfWjYErjYqoM09SJtFZHKCsAaaOoOx1H0yctc3T VxdWUjbkaPrkfAiXnjmyq8X7vYjd/kgZA4sZigleQzQfsgBEQ21o8PO++ojq2MH+pmB4 gbmG9zxXZC1hPXlze2OXNtuWPil42bB20zt1epkG+Sge0EWBC4SEh8TalVxVLOJLimOc 3reoDAMNHEKpgLxJ8ifJlYA9/PlDRAExQSMxLDIHYyO8lrj29NTv03bJECqIYPgXSgZT ruzjjVBT9ZFaNpG7zlmKhXBu52oZF3bjdpLgVseDmKjmqGkHCdo1q2UQI+53vtlhdQJJ B0aw==
X-Gm-Message-State: AOAM532mVjQ+A+9wK/srVeVk8j5+f9Q36mlW2GTucbsdUZMlZhbElRMg lpoyDjnSwtl6WapHKiicKVzaToGWUGLn1cH64lQ=
X-Google-Smtp-Source: ABdhPJwbIr/574RHmMKGbWPJ4hPpkVgO+OXmSktx76xOYivbX4R6AVlZ288sIjHvZr4Tvt52rgLxdLle0udZv5pY0yc=
X-Received: by 2002:a05:6e02:df1:: with SMTP id m17mr17435255ilj.276.1600223692326; Tue, 15 Sep 2020 19:34:52 -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>
In-Reply-To: <D0617842-4E1A-43A1-9933-9C8737B4F4F4@verisign.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 15 Sep 2020 22:34:40 -0400
Message-ID: <CAF4+nEGtAFnxQvBNpqBOY7Hd0ottn5E9_p=kBbS8VEMpRzx1-Q@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="000000000000be4f4605af651ce5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/GqcIemTHEf9igKmOS9EFmDcjmNw>
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: Wed, 16 Sep 2020 02:35:11 -0000
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