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

[Paul Wouters <[e-mail]>]

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