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

[Kent Watsen <[e-mail]>]

Hi Roman,

Please find comments below.

PS: I’ll be publishing updates to all nine drafts this evening.

Kent



> On Feb 8, 2024, at 2:29 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> 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.

We agreed to remove this section in my earlier response to you today.
The guidance was weak...

Just the same, I answer your questions below…


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

To your comment, I’ll assume that “using keys” means that the keys were being accessed/conveyed via a NETCONF or RESTCONF protocol operation (e.g., <get-config>, <edit-config>, etc.).  More specifically, “using keys” that not mean that the keys were participating in a cryptographic operation.

The impact is that the key should be destroyed, as its strength has been weaken to the strength of the underlying protocol.  E.g., a 4096 key conveyed over a 1024 transport is really as strong as the 1024 key.


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

The word “access” was being used to mean "conveyed in the payload of a NETCONF or RESTCONF protocol operation”.


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

Agreed, this is why we removed Section 3.5.


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

Section 3.6 was removed also, because there is no reason for this document to repeat guidance that must exist elsewhere.


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

It’s gone!  


Thanks again,
Kent