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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
