Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-crypto-types-29: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Murray,

Thank you for your valuable comments.
Please find responses below.

Reminder to all IESG members: if my response ever suggests that an update has been made, i.e., using words like “fixed” or “updated”, please know that I always mean that the update has been made in my local copy.  It is my intention to publish a bulk-update (to all nine drafts) once the churn dies down on these first three drafts.

Kent


> On Feb 1, 2024, at 2:46 AM, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-netconf-crypto-types-29: 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:
> ----------------------------------------------------------------------
> 
> Similar to what Paul's DISCUSS says:
> 
> 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.
> 
> Can we make a reference to said opinion?  Without that, this looks like
> argument from authority (and an anonymous one at that).


This seems like a duplicate to your email I just replied to.  
I guess that you added to your DISCUSS the extra bits below?


> ===
> 
> Additional comments from incoming ART AD, Orie Steele:
> 
> Section 1.4
> 
> Prefer to see the exact base64 format cited (not base64url, with or without
> padding , etc...)

This text now references Section 4, RFC 4648, per comments from Francesca and Carsten.


> I assume normative terminology in the model itself, does not contradict the
> RFCs from which it is derived?

What text is this comment connected to?


>> "A private key and, optionally, its associated public key.
>> Implementations SHOULD ensure that the two keys, when both
>> are specified, are a matching pair.";
> 
> Why not MUST?

Changed to a MUST - thanks!


>> "A private/public key pair and an associated certificate.
>> Implementations SHOULD assert that the certificate contains
>> the matching public key.";
> 
> Why not MUST?

Changed to a MUST - thanks!


>> "A private/public key pair and a list of associated
>> certificates.  Implementations SHOULD assert that
>> certificates contain the matching public key.";
> 
> Why not MUST?

Changed to a MUST - thanks!


>> 3.3. Unconstrained Public Key Usage
> 
> This seems not great. later...
> 
>> whereby associated certificates may constrain the usage of the public key
> according to local policy.
> ...
>> whereby configured certificates (e.g., identity certificates) may constrain
> the use of the public key according to local policy.
> 
> Why is this not a SHOULD / MUST ?

You’re right.
I changed the “may” to a MUST.



>> 3.5. Strength of Keys Conveyed
> 
> it might be better to convert this to a recommendation, with MUST NOT / SHOULD
> NOT, etc...

Agreed, I made this change:

-          <t>When accessing key values, it is desireable that implementations
+          <t>When accessing key values, implementations SHOULD



>> Implementations SHOULD only use secure transport protocols meeting local
> policy.
> 
> Why not MUST ?

I removed this entire Security Recommendation ("Use of Recommended Ciphersuites”) per a previous comment, so nothing to do now?   :)


>> This module defines storage for cleartext key values that SHOULD be zeroized
> when deleted, so as to prevent the remnants of their persisted storage
> locations from being analyzed in any meaningful way.
> 
> Nice to see this recommendation.

:)


Thanks again!
Kent