Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09
"Wessels, Duane" <dwessels@verisign.com> Mon, 21 September 2020 17:31 UTC
Return-Path: <dwessels@verisign.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 6629B3A09CE; Mon, 21 Sep 2020 10:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=verisign.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 hTdNjrpCbIki; Mon, 21 Sep 2020 10:31:37 -0700 (PDT)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C42F3A09C5; Mon, 21 Sep 2020 10:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=16375; q=dns/txt; s=VRSN; t=1600709497; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=iABkg942Lj5fcoyJdZ9us+BWsc8h6RrU36PZW4IW5MY=; b=a2AUKULLgS024O/ma3fq38QxEG2NiHGWKieirw2Em9FfyLcyfFWrOfRU mknUhsOrmCXE9y+exD/CX3QkGhBa7kUEFGvs+KLgsRJtqNegTUbcGwkXm l3luFrCaqfHptftN+g2hmR8pUACA8ZUft59kaU3W++teug2QJ7/Jh1glV uTqjl5lEdLuJJiF011ePfKTWtOPSdL62tQbZy9NpgXVyZG5XyIvow9k/u UWHykYNYYtu/vAPo3M2j+WCoIbRtJq0sPQ0+LAytSCMfQxZjKLEpCfkob zejheK4/jH95ZkL2teDM1Ye+o8v4zB2/nXk/rWPPegtpzX7EiwKY0a0Tg g==;
IronPort-SDR: Pzqk5Pe/TKXQWZRBfQSIIffzc+9AQUZQXTTQm+1S4Y/cHNpVdav3uAADQcwE4/qNRmzt7ccGkE L2vXxAfNMXv3g5PboXEOixghsW4iyNR/oWUg55wRyU6IJNL8d5soRqI/BVBoTrD7zFAl3xwm4N /vDz12IWyw0rBbJ5BI7PmDAw7t6KJhNTydUC4gkAn/InwXnDqgvVZT/t1hL01RLEwAy3BNHLy8 XU8coZx+CjkGxwJ7lAZxP/FhyQv0hNC1xeLp0sI+xVRyBsEOsi7mXTsV07Hx9BcO9B1Zs6vp4N gM0=
X-IronPort-AV: E=Sophos; i="5.77,287,1596513600"; d="p7s'?scan'208"; a="2984657"
IronPort-PHdr: 9a23:kk5jkhQnS/sGd0TzLLfI1RYA7dpsv+yvbD5Q0YIujvd0So/mwa67ZRCAt8tkgFKBZ4jH8fUM07OQ7/m/HzVaqs/Z4ThCKMUKC0Zbz51O3kQJO42sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7MhdpdKyuQtaBx8u42Pqv9JLNfg5GmCSyYa9oLBWxsA7dqtQajZFtJ6osyBbFuGZEd/pZyW91OV6emwv36sOs8JJ+6ShdtO8t+s9aXanmY6g0SKFTASg7PWwy+MDlrwTIQxGV5nsbXGUWkx5IDBbA4RrnQJr/sTb0u/Rk1iWCMsL4Ub47WTK576d2UxDokzsINyQ48G7MlMN9ir9QrQ+7qBx+x47UZ5yVNOZ7c6jAc94WWXZNU8BMXCFHH4iybZYAD/AZMOhYsYfzukcOoxW9CwmiBuzhzT5IiWP50qAh3OQtDQTG0RYgH94SrnjZqsj+OqcIUeCyyanF1TvPYPNI1jfm84jHbBQhoeqUUbltf8TR1FMgFwXbgVmetIfoOC6a1+oTvGiA9OpvS+avi3U8pgFvvDev3MYsipLIhoIazFDI7zl2wIEwJdChTkNwfNGrHodKuS6AK4t2Xt0tQ3tuuCsiy7ALvYK3cDQKxZg6xBPSdv+KfYeI7x7+VOidPSp1iXJrdbywhRu88VWsx+PyWMe61FtHrCRLn9vSun0D1xLf9M6KQeZz8Eem3DaAzQHT6udcLEA1i6XbN5AhzqQ3lpoJvkTOGDL9lkbujKKOa0ko5vKk5/nlb7jovJOQKo95hw/kPqkhnsGzGfk0PhQUU2SG++mwyKfv8VD2TbhJlPE6j6rUvZbHLsoBvKG5GRVa0oM75ha6CDepzcoXkGEcLFJAZBKHl4/pO0zSIPzgDfewnVCskDBzyv3bIrPvGojBIXjbnrnufLlx91BQxBAtzd9D4JJUEKkBLOjpVUDsrtDYEAU5Mxeyw+r9FNp90YYeVXqOAq+fLqzSrUeF6v8zL+WWeYMYujjwJ+I46/Pug3I1g1AQcK2x0ZsScn+4H/BmI0uDYXrrh9cMCXoFvwQgQ+zxk12NTzpTZ22pUqIi+D47EoOmDZzCRoCihryNxju0HppTZmxeEFCDDW/od5mYW/cLcC+dP8FsnSIKWLe/RYIszh6utArgxLpmKurY4DEXtZXm1NJt/e3ciQky9SBoD8Say2yNTn97nngHRzIt3aBwv1B9ylmZ3ah/mfxYGsRZ5+lVXQciKZ7c0+t6BsjvVQLbZNiJRkqmTsynAT4vUtIxzcYCbFt7G9W5iRDDxzOmDKITl7yQHZA186Xc337vKMpk1nnG1aYhgEc9QstTL2GpnKp/9wzICo7IjUqZi6iqeb4b3C7X+2eJ1XCOs11AUA5sTaXFWmgSZlDIotvl+0zCTqWuBK8mMgRf1c6CJLFGatrzjVVJF7/fP4HyZGS4n2v4KB+T2reFb4eiL2lG0X7QU2ALlgkS+TCNMg1oVQm7pGeLRgNjDkniZ1ioucVjoXW2BAdgwx6HdFZs06Gd5BMPhOedRPVV1bUB7nRy4w5oFUqwioqFQ+GLoBBsKf1R
X-IPAS-Result: A2FYAAD84mhf/zGZrQpcAxoBAQEBAQEBAQEBAwEBAQESAQEBAQICAQEBAUCBT4F1BoEfLIEICpVyg3qGFJAogWkEBwEBAQEBAQEBAQQEASUKBAEBAoRJAoItJTgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGRQyCNyJ7gQMBAQEBAQEBAQEBAQEBAQEBAQEBFgJDVRIBAR0BAQEBAgF5BQsCAQgOChUZAh8RJQIEDgUOgxgBgksDDhEemQmaZnSBNIQ/Ag5BgxkNghQKBoE4gVOEeIUeJYE5gUI+gREnHIJNPoIaQgEBAgEBgRQtGRgKHgiDA4ItBItQhDkLLqVkN1EDB4JnhEWCX4FSi2RqhQsegwyPMY5EnVyCao5Vg1wCBAIEBQIVgWuBe3AVOyoBggoBATI+EhcCDY4oAgEXgQIBDIdThUJ0NAMCBgoBAQMJjBstgQYxYAEB
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 21 Sep 2020 13:31:34 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.1979.003; Mon, 21 Sep 2020 13:31:34 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Donald Eastlake <d3e3e3@gmail.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>
Thread-Topic: [EXTERNAL] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09
Thread-Index: AQHWkD0NBk7hWiirA0qu4ZMMGkGTEQ==
Date: Mon, 21 Sep 2020 17:31:34 +0000
Message-ID: <D2C49B4C-8C93-4FBA-BE94-6EFBA83BBBED@verisign.com>
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>
In-Reply-To: <CAF4+nEGtAFnxQvBNpqBOY7Hd0ottn5E9_p=kBbS8VEMpRzx1-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.15)
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_26328243-7C53-41C7-832F-932D33B5FA77"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/OLMtzOTKq1I5R9Wx9PfiYLeoAh8>
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 17:31:39 -0000
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