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

From: Tim Wicinski <[email-masked]>
Date: Tue, 1 Feb 2022 15:35:26 -0500

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

---------- 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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 1 Feb 2022 18:04:03 -0500

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

> With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time 
> to move this document along as well.
>
> "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource 
> Records for DNSSEC"
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Russ Housley <[email-masked]>
Date: Sat, 5 Feb 2022 11:19:09 -0500

Tim:

I looked at the diff between draft-ietf-dnsop-rfc5933-bis and RFC 5933.  The changes seems reasonable to me.

Russ

> On Feb 1, 2022, at 3:35 PM, Tim Wicinski <[email-masked]> 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
> 
> 
> With draft-ietf-dnsop-dnssec-iana-cons now in AUTH48 state, it's time to move this document along as well.    
> 
> "Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC"
> 
> https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html <https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-07.html>
> 
> 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