Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
draft-ietf-dnsop-rfc5933-bis-14

This document was replaced by draft-makarenko-gost2012-dnssec, which is being progressed through the ISE.

I was holding draft-ietf-dnsop-rfc5933-bis until draft-makarenko-gost2012-dnssec was sent to the RFC Editor, which has now happened -- https://datatracker.ietf.org/doc/draft-makarenko-gost2012-dnssec/history/

Much thanks to the WG, authors, ISE, etc.

[Ballot discuss]
(updated DISCUSS to -13, thanks for addressing my DISCUSS items on -12)

I agree with Roman's DISCUSS on the stream of the document, and his proposed solution.

[Ballot comment]
The document is short and readable, I have no objection to it as such. Roman's DISCUSS position makes sense to me, however, as does his proposed solution (even though the additional work is regrettable).

[Ballot discuss]
I agree with Roman's DISCUSS on the stream of the document, and his proposed solution.

Additionally, I have some items:

  According to RFC6840 [RFC6840], Section 5.2 systems that
  do not support these algorithms may ignore the RRSIG, DNSKEY and DS
  records created with them.

I do not read that as "may" (lowercase), but more as a MUST. That is, returning a ServFail when you see these is not allowed. The "may" here means that thiswould be a valid response.

    Zone Signing field should be changed to "N".

I believe I already mentioned this before. This change should NOT be made. The deprecated value is one that was only valid for Zone Signing. Deprecating the algorithm should not change its existing function.

[Ballot comment]
    RFC 4033 [RFC4033], RFC 4034
  [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
  Extensions, called DNSSEC.

This document could be the first user of using [BCPxx] (draft-ietf-dnsop-dnssec-bcp, currently at RFC Editor) instead of referencing an incomplete set of what DNSSEC is.

  Note: Algorithm numbers 23 and 5 are used in this document as an
  example, since the actual numbers have not yet been assigned.

This note should be more clearly marked using [brackets] so that the RFC Editor knows it is meant for them to remove/update and/or the authors to update upon their allocation and updated examples

[Ballot discuss]
(updated ballot)

The IETF has steered away from publishing protocol mechanisms with dependencies on national cryptography as we do not have the ability to validate their security properties ourselves.  IETF stream documents typically rely on documents published in the Crypto Forum Research Group (CFRG) [1]; an open and peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to give us confidence in cryptographic algorithm choices. Since the described GOST mechanism doesn’t fit into these vetting criteria and the WG (based on the shepherd’s report) has not provided alternative analysis, it is not appropriate to publish this document in the IETF stream.

11/28/2022: Suggested resolution per mailing list discussion: https://mailarchive.ietf.org/arch/msg/dnsop/XZoakWUDruPXylJ2wLIS4l4vevo/

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-rfc5933-bis-12
CC @ekline

## Comments

* I'll defer to SEC ADs on the appropriate course of action, notwithstanding
  the fact that this is a bis of a previous Standards Track document.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-rfc5933-bis-12

CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I share Roman's feeling about the ISE stream rather than the IETF stream, especially since 'informative' is enough.

Special thanks to Tim Wicinski for the shepherd's detailed write-up including the WG consensus *but* missing the justification of the intended status (even if the write-up alludes to informational is enough).

Thanks to Jim Reid and Scott Rose who did the DNS directorate reviews of this document (even if the expectation of DNS directorate is to focus on documents from non DNS WGs):

* https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc5933-bis-10-dnsdir-lc-reid-2022-10-16/
* https://datatracker.ietf.org/doc/review-ietf-dnsop-rfc5933-bis-12-dnsdir-telechat-rose-2022-11-02/

Alas no public reaction by the authors...

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Consensus boilerplate

It is missing ;-)

### Section 2.2

Suggest to add a RFC editor note with a request to update the text when the official allocation is known (and redo the math of course). Last paragraph of section 10 should be more detailed.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
I support Roman's discuss.

I would rather see this document be published by the ISE than go through the IETF stream.  My specific concern is than an operator who reads this RFC and doesn't know the context may not be aware that this may be an inappropriate algorithm to use.  Even if this is published via the ISE channel then I think that it should be stated very clearly early in the document that the cryptographic properties haven't been independently verified.

Regards,
Rob

[Ballot discuss]
The IETF has steered away from publishing protocol mechanisms with dependencies on national cryptography as we do not have the ability to validate their security properties ourselves.  IETF stream documents typically rely on documents published in the Crypto Forum Research Group (CFRG) [1]; an open and peer-reviewed vetting process; or a review by the IRTF Crypto Panel [2] to give us confidence in cryptographic algorithm choices. Since the described GOST mechanism doesn’t fit into these vetting criteria and the WG (based on the shepherd’s report) has not provided alternative analysis, it is not appropriate to publish this document in the IETF stream.

[Ballot comment]
Thank you to Mohti Sethi for the SECDIR review.

I have no insight into the deliberations in 2010 that resulted in RFC5933 being published.  However, as the shepherd’s report notes, with the publication of RFC6014 (in 2010) and RFC9157 (in 2021), the relevant IANA DNSSEC registries [4] [5] provide sufficient flexibility to assign code points with an RFC outside of the IETF stream (a situation that didn’t exist in 2010).  Such flexible policies in DNSSEC registries have also been made for TLS and IPsec registries to avoid the IETF having to render judgement on cryptography, national or otherwise, while still providing code points -- the exact situation we find ourselves in.  Similar GOST-related protocol mechanisms have successfully been submitted to the Independent Submission Stream (ISE) [3] (e.g., RFC 9189, draft-smyslov-ike2-gost, and draft-smyshlyaev-tls13-gost-suites).  It seems possible to follow the same approach here.

[1] https://datatracker.ietf.org/rg/cfrg/about/
[2] https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel
[3] https://www.rfc-editor.org/about/independent/
[4] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
[5] https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-rfc5933-bis-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that, upon approval of this document, there are four actions which we must complete.

First, in the DNS Security Algorithm Numbers registry on the Domain Name System Security (DNSSEC) Algorithm Numbers registry page located at:

https://www.iana.org/assignments/dns-sec-alg-numbers/

a new registration will be made as follows:

Number: [ TBD-at-Registration ]
Description: GOST R 34.10-2012
Mnemonic: ECC-GOST12
Zone Signing: Y
Trans. Sec. : *
Reference: [ RFC-to-be ]

Second, also in the DNS Security Algorithm Numbers registry on the Domain Name System Security (DNSSEC) Algorithm Numbers registry page located at:

https://www.iana.org/assignments/dns-sec-alg-numbers/

the entry for the Algorithm "GOST R 34.10-2001", number 12 will have its Description field should be changed to "GOST R 34.10-2001 (deprecated, see [ TBD-at-Registration ]" and Zone Signing field should be changed to "N" (where [ TBD-at-Registration ] is the value from the first IANA action for this document).

Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry located at:

https://www.iana.org/assignments/ds-rr-types/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: GOST R 34.11-2012
Status:
Reference: [ RFC-to-be ]

IANA Question --> What should the entry for "Status" be for this new registration?

Fourth, also in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry located at:

https://www.iana.org/assignments/ds-rr-types/

the entry for Value 3, GOST R 34.11-94 should be updated to have its Status changed to '-'.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-19):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc5933-bis@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Use of GOST 2012 Signature
Algorithms in DNSKEY and RRSIG Resource
  Records for DNSSEC'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how to produce digital signatures and hash
  functions using the GOST R 34.10-2012 and GOST R 34.11-2012
  algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
  Domain Name System Security Extensions (DNSSEC).

  This document obsoletes RFC 5933 and updates RFC 8624.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. WG has consensus eventually.

2.  There was controvesry when the document was first proposed.  There was
    issues raise such as nationalistic cryptography, or algorithms.
    Issues were also raised that initially the document was Proposed Standards,
    which was needed to update the IANA registry.  However, during working
    group discussions, it was discovered that RFC6014 which updated the registries
    to not always require Standards Track documents missed an IANA registry.
    RFC9157 was published to address this issue.  Once that was completed
    the document could proceed as Infomational.


3. No appeals threatened

4. There are implementations of this algorithm.

## Additional Reviews

5. Other reviews such as security would be useful

6. No formal expert reviews needed

7. No Yang

8. No automated checks

## Document Shepherd Checks

9.  Shepherd feels document is clearly written and ready to be handed off.

10. All outside issues addressed

11. RFC is being requested as Informational, and this is the correct RFC type.
    Datatracker attributes are correct.

12. All authors reminded of IPR.

13. All authors are listed willingly.

14. No current nits

15. All references are accurate

16. All references freely available

17. No downward normative references

18. All normatives references have been published

19. This document will Obsolete RFC5933, and Update RFC8624.  This is relected
    in the abstract and discussed in the introduction.

20. IANA considerations section is consistent with document.

21. No new IANA registries

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. WG has consensus eventually.

2.  There was controvesry when the document was first proposed.  There was
    issues raise such as nationalistic cryptography, or algorithms.
    Issues were also raised that initially the document was Proposed Standards,
    which was needed to update the IANA registry.  However, during working
    group discussions, it was discovered that RFC6014 which updated the registries
    to not always require Standards Track documents missed an IANA registry.
    RFC9157 was published to address this issue.  Once that was completed
    the document could proceed as Infomational.


3. No appeals threatened

4. There are implementations of this algorithm.

## Additional Reviews

5. Other reviews such as security would be useful

6. No formal expert reviews needed

7. No Yang

8. No automated checks

## Document Shepherd Checks

9.  Shepherd feels document is clearly written and ready to be handed off.

10. All outside issues addressed

11. RFC is being requested as Informational, and this is the correct RFC type.
    Datatracker attributes are correct.

12. All authors reminded of IPR.

13. All authors are listed willingly.

14. No current nits

15. All references are accurate

16. All references freely available

17. No downward normative references

18. All normatives references have been published

19. This document will Obsolete RFC5933, and Update RFC8624.  This is relected
    in the abstract and discussed in the introduction.

20. IANA considerations section is consistent with document.

21. No new IANA registries