Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

Paul Wouters <paul.wouters@aiven.io> Mon, 11 July 2022 17:08 UTC

Return-Path: <paul.wouters@aiven.io>
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 33AE6C18871C for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2022 10:08:21 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz8-QURtN5Mq for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2022 10:08:17 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C88EC15948B for <dnsop@ietf.org>; Mon, 11 Jul 2022 10:08:17 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id j22so9933236ejs.2 for <dnsop@ietf.org>; Mon, 11 Jul 2022 10:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:message-id:mime-version; bh=TPidieJpu1Xl+1bhwd7qPsQFtF0T92Tscn6IbkEPqDE=; b=fbA9Zqlv4jjE7P9SA9DMjqkLvq8Xm0z95S0/qU7BFLiBAPKrI80TGrnEGznwKM6Gl4 T4tWT4svrd9g+tRTNrljZOGeCvCu2grt04Iuh0lvXiiCnZXHYB55vHbgGxfmXYy44cXX LxkSgLk/qBC/pStWEdswEc+HlI/480YDfiJ08=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version; bh=TPidieJpu1Xl+1bhwd7qPsQFtF0T92Tscn6IbkEPqDE=; b=bpP64rQ+oerns9OuUMcHKAZsVuN/mCtX3Vz85WFgkan0YkizpUoo9lOv5fQHyVoPXW xCMHWavQrsiy3zJ+aj30QPJvCpNSiH0YfeZkaLm55vBabENTKKmf+ZjARSXRBmnOS1oC yN2W+RVnd1GM6njiMMtMYoSyDTjUqWPw7BdujSK5f/8EFiPjXdOfxoF9yVTuurQmuEEv GqbY37z7yb3T5Skta8b+4tOEmD7kbjem8AdgFWT9x5SSXuJYm5i7UnrZEE536Q64A2lj xappJ1fIYutP8YD7Vp6vACsv43ZrBkWDjhZwLCmgMZii75Ey6PT3iLuX7ShMEQnoP9vp tFAA==
X-Gm-Message-State: AJIora8Z/mNDw9Ublk1rpH+l8+vxw7qFwN5loxpvWA8vTYMaB/mzZyVF vV384kQS8MNfMHpYnH12qqWH3Cf66laOlhcu
X-Google-Smtp-Source: AGRyM1tpvbaU/JnCFgBgQHrS5buS9leofAGTPnqx7TOCzmN9s9S57mnMHlv2tx0N40ODa2Hv4jPTkg==
X-Received: by 2002:a17:906:106:b0:722:e997:a365 with SMTP id 6-20020a170906010600b00722e997a365mr19758734eje.169.1657559295075; Mon, 11 Jul 2022 10:08:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id d10-20020aa7d5ca000000b0043586bee560sm4585175eds.68.2022.07.11.10.08.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 10:08:14 -0700 (PDT)
Date: Mon, 11 Jul 2022 13:08:11 -0400
From: Paul Wouters <paul.wouters@aiven.io>
To: Dmitry Belyavsky <beldmit@gmail.com>
cc: dnsop <dnsop@ietf.org>
Message-ID: <5847ea19-a8bd-de8d-2edc-e2da60667c91@aiven.io>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_C84aPla9pMId3kzyiCA180d2a8>
Subject: Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 11 Jul 2022 17:08:21 -0000

On Sun, 10 Jul 2022, Dmitry Belyavsky wrote:

> Sorry for a very=C2=A0long delay, as your review was the only one I thoug=
ht there was not enough interest in
> this document.

It escaped my attention. I have done a review now, and the document
looks okay, but still needs some changes I think.


>       The algorithm number is specified as 23 here and other places, and that's so that the examples
>       could be calculated, but if the IANA doesn't issue them 23 as the number (and they probably
>       won't) most of the examples will have to be redone with the final values.=C2=A0 This is a cart/horse
>       problem and I'd recommend that the IANA do an early=C2=A0 assignment of the signature and digest
>       algorithm values and that the document be redone with the final values prior to IESG submission
>       to prevent a round trip during RFC publication.

I agree. The document adoption already signaled the non-technical
issues, eg whether or not the IETF should add GOST algorithms. Since
we are now at the implementation stage, I think an Early Allocation is
the right way forward. If not doing this, please add a notes in [square
brackets] about this assumed calculation so it won't be forgotten in
future versions. (I see this was done now already, thanks)

>       Section 6.1 - huh?=C2=A0 In any case, we generally don't have single subheader sections - move the
>       text up.=C2=A0=C2=A0 I think this is supposed to be "The support of this cryptographic suite in
>       DNSSEC-aware systems is OPTIONAL.=C2=A0 Systems that do not support these algorithms may ignore the
>       RRSIG, DNSKEY and DS records created with them."

I think giving directions here about what to do when not supported is
wrong. It should at most point to the generic DNSSEC handling of unknown
algorithms, as this is not a special case. eg point to
https://datatracker.ietf.org/doc/html/rfc6840#section-5.2


Setion 2.1 says:

    The signature is calculated from the hash according to the GOST R
    34.10-2012 standard, and its wire format is compatible with RFC 7091
    [RFC7091].

I find the use of "compatible" a bit strange. Is it the wire format or
isn't it?

    Note: The ECC-GOST12 signature algorithm uses random data, so the
    actual computed signature value will differ between signature
    calculations.

Do common libraries not support a method where this data is static, to
facilitate testing code with static test vectors? That would really be
needed to be able to verify an implementtion with provided test vectors.

Section 4.1 prob should use TBD1 and not 23, until we have an Early Code
assignment.

Setion 5, we usually don't use "Deployment Considerations" but use
"Operational Considerations", and then look at RFC 5706 for guidance
on its content.

Section 6:

    The support of this cryptographic suite in DNSSEC-aware systems is
    OPTIONAL.  Systems that do not support these algorithms may ignore
    the RRSIG, DNSKEY and DS records created with them.

Maybe point to https://datatracker.ietf.org/doc/html/rfc6840#section-5.2


It would be good if Section 7 and/or 8 could give a more informative
instruction to developers. My understanding is that GOST R 34.10-2001
GOST R 34.11-94 are not deployed anywhere, so the advise could be along
the lines of:

    As GOST R 34.10-2001 and GOST R 34.11-94 are not used in
    production deployments, these deprecated algorithms MUST NOT be
    implemented or used for DNSSEC signing or DNSSEC validation.


I think Section 9 needs a little work. A protocol implementer doesn't
really need to know the cryptogrpahic strength. I think it is far more
valuable to give some advise on deploying this too soon, without
widespread support, and having your domain being handled as unsigned.

Perhaps recommend a dual KSK/algorithm signed zone at first until these
algorithms are more widely supported so those who want to use GOST have
a migration path towards those algorithms?

Section 10:

    Value  Algorithm         Mnemonic  Signing Sec.  References   Status
    TBA1   GOST R 34.10-2012 ECC-GOST12    Y   *     RFC TBA     OPTIONAL

There is no Status column in this registry (they should prob be one,
but right now it doesn't have one).

    The entry for the Algorithm "GOST R 34.10-2001", number 12 should be
    updated as such: Description field should be changed to "GOST R
    34.10-2001 (deprecated, see TBA1" and Zone Signing field should be
    changed to "N".

I don't think the Zone Signing field should be updated. This field
basically means "For use with DNSSEC" (not SIG0), which the entries
were defined for. It is not used to convey "is currently okay to use
for zone signing".


NITS:

I would not use "according to RFC-xxxx" but perhaps just place the RFC
link there (but not to the entire document but straight into the
relevant section)

Paul