[DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance

Warren Kumari <warren@kumari.net> Wed, 13 April 2022 16:37 UTC

Return-Path: <warren@kumari.net>
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 3B0473A17DC for <dnsop@ietfa.amsl.com>; Wed, 13 Apr 2022 09:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 s_Oa7GyDmlJ1 for <dnsop@ietfa.amsl.com>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 876AC3A17DB for <dnsop@ietf.org>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id lc2so5057044ejb.12 for <dnsop@ietf.org>; Wed, 13 Apr 2022 09:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=cd1q8QbN7XjQcnR98QjcurDoQHqGWhb5qvLdH5vMURNHLOx8n/a+ePttQz4BISzbpz ojBGilgnZUoKBaMcLPikOX4CyorYolAypqZGYTsRWsoJ5k9QO6rw1Tfug7PNk/ym0cdX mxTKNtDTLrvs5umIMunfNNLb6nqqy4zAPLZIPVz1GxPncAKrA7NbM/tyw70teEnyHguh zbONiOnSJ13pApXbMulyzvTnq0QGzRRVzqPA4rjQ5O9ghmWz6wuWUOZoQvbHHnQVWX2k 00vmCWbnR32ORsuK/clkA2n7lhJLBDvrCkuSfWTsNDybW2rzI5ZJtZwcKkh0j3si/q5Q /f4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=56WmDZUEh1oTqb3AYmNgnkig/jOdtr8zUBuOXILCysM=; b=jMEbwUwsfuppHX6gECfJy9PSwD9lT81M+hs/Ci5Cy+GIwGt0tP3fUXVNitxY9zoBdy tlkHNEP/6PJkNB1bXnWIWuFAxHlhK+6TH00P3V7UzSgS4GcORGvrhtPzVPxZ4jdpEaiX MjpfbOXVlikdgXJcDnh8+RkVHk82lOmjR107otVLsgMdLOLaXsB9TMQ8oa8SqKvMrazM DnRkF9TQXISlYHD7nA8SIVslneOuCbFuo4ctBLjl1uKnvsJcph2v4ZZiuHftgJovNoNJ /xbZC6oYi87mr8r8dlhTedRJB4VgGJ2ehMsuak8rqAkK7KHDAQmm1fhPLbxfS15Mdczn 2Nlw==
X-Gm-Message-State: AOAM531si/wnZRHyNFfL1Fbf/XcedheuawalJBaGJcpeE53oO7HERU1/ VeScey9QGSvZ9pAVOck10oBgVs5lVcvyvxRTyG4C+A==
X-Google-Smtp-Source: ABdhPJzDL0hsIO+Rb/S6sYF1c++7qtmopUVxbvxnzBzhUZdOwCGAgCMk//n+hRcsxUdh8gbmgUYzv47qcq9yvMnxVys=
X-Received: by 2002:a17:907:7b92:b0:6db:71f1:fc20 with SMTP id ne18-20020a1709077b9200b006db71f1fc20mr38443294ejc.343.1649867857086; Wed, 13 Apr 2022 09:37:37 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Apr 2022 09:37:35 -0700
Mime-Version: 1.0
X-Superhuman-ID: l1xspkgk.fea655e2-c3d0-4485-bca9-6e4ef0b6d877
X-Superhuman-Draft-ID: draft009dd8d3b63c8c55
X-Superhuman-Thread-ID: draft00e683a07df3c2ee
X-Mailer: Superhuman Desktop (2022-04-12T22:06:10Z)
From: Warren Kumari <warren@kumari.net>
Date: Wed, 13 Apr 2022 09:37:35 -0700
Message-ID: <CAHw9_i++SupWXyLsyksO3CYa5r9ukJbs1=Of9VmnSDXycNRWYA@mail.gmail.com>
To: draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c650905dc8bcbb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MpW5sqXC8FJarh8KwDoG8P94pRs>
Subject: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Apr 2022 16:37:45 -0000

Hi there, authors (and WG),

Thank you for this document, I found it clear, useful, and an easy read.

I do have a few comments/nits; addressing these now should help the IETF LC
and IESG evaluation go more smoothly.


Please SHOUT loudly once you've had a chance to address these, and I'll
start IETF LC.


Comments / questions:
------------------------------------
Abstract:
"NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising
there are no names that exist between two domainnames within a zone."

The "promising" in this feels a little odd to me — RFC4033 Sec 12 says that
"NSEC RRs **assert** which names do not exist..". RFC5155 talks about
"showing" that names don't exist — perhaps "by asserting that there are…"
would be better?

I'm (of course) happy to be told that "promising" was chosen for a reason
and that it's the right term.


Nits:
----------
Global:
The document uses the term 'domainname' - RFC8499 uses 'domain name'.
Looking through published RFCs, there are ~6200 instances of 'domain name',
~400 of 'domain-name' and <50 domainname (and many are in things like
ABNF). I'd suggest s/domainname/domain name/g.


Section 1 - Introduction
Use of the opt-out feature allow large registries to only sign as many NSEC3
[O] allow
[P] allows

 records as there are signed DS or other RRsets in the zone - with opt-out,
unsigned delegations don't require additional NSEC3 records.

[O] zone - with
[P] zone; with
[R] readability/grammar


Section 2.4 - Salt
This is true both when resigning the entire zone at once, or when
incrementally signing it in the background where the  new salt is only
activated once every name in the chain has been completed.
[O]: or
[P]: and
[C]: When using 'both' as a conjunction, it is 'both … and', not 'both …
or'; if this doesn't work, perhaps 'either … or'.

-----

Thank you again; I know that making edits to address nits can be annoying,
but we are expecting many people to read and review the document, and so
having it polished is important and polite (also, once people start
commenting on nits, they seem to continue :-) )
W