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

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for accepting my responses and clearing your DISCUSS position.
Please find more comments below.

Kent


> On Feb 8, 2024, at 2:27 PM, Roman Danyliw <[e-mail]> wrote:
> 
> 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 is the "Strength of Keys Conveyed” consideration.

Hmmm, I suppose this consideration is more directed at the servers than the clients.
If a key of greater strength is conveyed over a transport of lesser strength, I’d suspect that the key should be destroyed, as its strength is no longer assured - agreed?

That said, see next comment...



>>> ** 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.5 removed (thus above comment is mute)

PS: this is going to mess-up the Section-numbers.


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

This section (Use of Recommended Ciphersuites) was removed in -30 per another review comment.

Essentially, there is no need for this document to repeat guidance must appear in other documents, e.g., those the regard the protocols themselves, not just the configuration of client/server stacks...

Thus I’m unable to take any action here.

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

Kent