[netconf] Roman Danyliw's No Objection on draft-ietf-netconf-crypto-types-30: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-crypto-types-30: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Valery Smyslov for the SECDIR review.

I support the Paul's DISCUSS position.

Thanks for addressing my DISCUSS feedback and most of my COMMENT feedback.

** Section 3.5.
   When accessing key values, it is desireable that implementations
   ensure that the strength of the keys being accessed is not greater
   than the strength of the underlying secure transport connection over
   which the keys are conveyed.  However, comparing key strengths can be
   complicated and difficult to implement in practice.

I don’t understand the guidance in this section.  I would have benefited from
clarity in the following areas.

-- Explain the impact of using keys whose strength exceeds the underlying
transport connection (i.e., it doesn’t offer more security)

-- The verb “accessing” is confusing.  Let’s say that an implementation notices
a discrepancy between key strength, what is it supposed to do?

-- The last sentence (“However, comparing ...) seems to acknowledge (correctly)
that this advice might not be practical.  Is the WG sure the text is needed?

** Section 3.6
   Implementations SHOULD only use secure transport protocols meeting
   local policy.  A reasonable policy may, e.g., state that only
   ciphersuites listed as "recommended" by the IETF be used (e.g.,
   [RFC7525] for TLS).

-- Would there be instances where implementation would use secure transport
that _doesn’t_ meet local policy?

-- RFC7525 has been obsoleted.  s/RFC7525/RFC9325/