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

[Michael StJohns <[e-mail]>]

On 2/1/2022 3:35 PM, Tim Wicinski wrote:
> All
>
> We were reviewing the Working Group Last Call for this, and we 
> received no comments.  We know there was interest in at least moving 
> this forward, but even Warren concurred we can't send this to the IESG 
> unless there are folks saying they feel it is ready to be published.
>
> Thanks
>
> tim
>

Hi Tim -

Since you ask, I don't think it's ready to go forward.  Section 2 is 
particularly opaque.

Section 2.1 - Provide the ASN1 that explains what's going on by adding 
the prefix to a 64 byte GOST public key.  Ideally identify the various 
OIDs that match to the key format, and to the signature format.

Section 2.2 - How does the private key in the first part of the example 
get you to the public key in the second?

The Base 64 in the DNSKEY appears to give you this value:

5E 46 7A 4F  EA 90 F6 D7  8E 32 C0 3F  60 AF A4 4F
31 0B 86 E3  0F 4E C6 20  81 DC B6 6F  EB 1F CC 9E
AD 1F D7 A7  8B 38 8C 5F  78 23 32 75  19 23 2A E7
48 87 21 2E  3B A9 F3 1A  72 F9 45 39  97 51 32 8F

Which appears to be an unparameterized GOST public key which I assume 
matches the private key.  That may be a valid key or not, but saying 
that explicitly would be useful.    Or at least "The following DNSKEY RR 
contains the encoded GOST public key paired with this private key - see 
xxx for the key pair generation logic"

To fix all this, start from a normal (PEM or PKCS8 or PKCS12 or X509) 
representation of an example key pair and work from there to map to/form 
DNSKEY, DS and RRSIG records.

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.  This is a 
cart/horse problem and I'd recommend that the IANA do an early  
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.

Sections 3.1 and 4.1 - show your work.  Show the actual data being 
hashed or signed so that someone else coming along can verify that a) 
you did the encoding properly, and b) the hashes match or the signatures 
match.  This is especially important with algorithms which lack broad 
international implementation.

Section 5 - these should refer to the GOST specification  (e.g. "MUST be 
512 bits per [GOSTxxx]").  As stated, this could be something peculiar 
to this spec rather than the underlying cryptographic primitive.

Section 6.1 - huh?  In any case, we generally don't have single 
subheader sections - move the text up.   I think this is supposed to be 
"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."

Section 10: "

I hope this helps -

Mike

>
> ---------- Forwarded message ---------
>
> All
>
> With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time 
> to move this document along as well.
>
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc5933-bis,
> "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource 
> Records for DNSSEC"
>
> Current versions of the draft is available here:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html
>
> The Current Intended Status of this document is: Informational
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please 
> speak out with your reasons.
>
> Because of the American holiday, we're going to run the last call 
> process a few days long.   This Working Group Last Call will end on: 
>  10 December 2021
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop