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

Discuss

Paul Wouters
Roman Danyliw

Yes

(Warren Kumari)

No Objection

Éric Vyncke
(John Scudder)
(Murray Kucherawy)
(Robert Wilton)

Abstain

Erik Kline

No Record

Andy Newton
Deb Cooley
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Orie Steele

Summary: Needs a YES. Has 2 DISCUSSes.

Paul Wouters
Discuss
Discuss (2023-02-07 for -13) Sent for earlier 
(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.
Comment (2022-11-29 for -13) Sent for earlier 
    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
Roman Danyliw
Discuss
Discuss (2022-11-29 for -12) Sent 
(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/
Comment (2022-11-17 for -12) Sent 
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
Éric Vyncke
No Objection
Comment (2022-11-28 for -12) Sent 
# É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
Erik Kline
Abstain
Comment (2022-11-28 for -12) Not sent 
# 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.
Andy Newton
No Record
Deb Cooley
No Record
Gorry Fairhurst
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Ketan Talaulikar
No Record
Mahesh Jethanandani
No Record
Mike Bishop
No Record
Mohamed Boucadair
No Record
Orie Steele
No Record
Warren Kumari Former IESG member
Yes
Yes (for -12) Unknown 

                            

                        
                    

                
            
        
            
                
            
                
                    

                        

                            John Scudder Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2022-11-30 for -13)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

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

                            

                        
                    

                
            
                
                    

                        

                            Murray Kucherawy Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2022-11-30 for -13)
                                
                                
                                    
                                         Not sent
                                    
                                
                            

                        

                        
                            

                                
I support Roman's DISCUSS.

                            

                        
                    

                
            
                
                    

                        

                            Robert Wilton Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2022-11-25 for -12)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

                                
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