Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-crypto-types-29: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Kent!

Thanks for your detailed response and for producing -30.  I've cleared my DISCUSS position.  One response below to a COMMENT ...

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Kent Watsen
> Sent: Wednesday, January 31, 2024 12:09 PM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-crypto-
> types-29: (with DISCUSS and COMMENT)

[snip]

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

I appreciate the revised text.  I'm still no clear on what action implementations should take on detection of the mismatch.

> > ** Section 3.5.
> >   That said, expert Security opinion suggests that already it is
> >   infeasible to break a 128-bit symmetric key using a classical
> >   computer, and thus the concern for conveying higher-strength keys
> >   begins to lose its allure.
> >
> > Recommend removing this generic statement.  There would be a variety
> > of reasons operators might choose to use symmetric keys in excess of
> > 128-bits, policy being one of them.
> 
> I’m happy to remove Section 3.5 (Strength of Keys Conveyed) entirely.
> 
> IDK if there is any value to keeping it.   I only added it because it is something
> I remembered from a past life.  No one ever asked me to add this Section...
> 
> Is my understanding from your "Is the WG sure the text is needed?” above that
> you lean towards removing Section 3.5?

Exactly.  I didn't find the guidance actionable.


> > ** 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?
> 
> Shouldn’t be, but maybe a rouge new employee doesn’t know it ;)
> 
> Is your point that we should s/SHOULD/MUST/ here?

Yes, exactly.

> > -- RFC7525 has been obsoleted.  s/RFC7525/RFC9325/
> Updated - thanks!

Roman