[netconf] Paul Wouters' Discuss on draft-ietf-netconf-crypto-types-29: (with DISCUSS and COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-netconf-crypto-types-29: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to Valery and Rifaat for their secdir reviews. I have some items I would
like some clarifications on and some non-blocking comments.

2.1.4.12 contains:

  +-- certificates
    |  +-- certificate* [name]
    |     +-- name?                       string

Certificate identity is either done by entire DN, The Common Name (CN) RDN,
or by a list of subjectAltName (SAN) entries. Can the latter be expressed
here? Should a type be introduced? ("CN", "DN", "SAN") ? Should the type be
a list as 1 certificate can have multiple identities via multiple SAN entries.

2.2.1 talks about "asymmetric key" without specifying if it is referring to
a public key or a private key. I think "private" is mean here on all occasions.
Should that be clarified?

2.2.1.2 uses "cleartext-key" and "cleartext-private-key". Would it not be less
confusing to rename "cleartext-key" to "cleartext-sym-key" ?

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.

I don't think this document should make this statement.

Section 3.6 Use of Recommended Ciphersuites

Why is this document containing this single recommendation ?  I would
rename this section to "Use of Secure Transport Protocols" and refer
to RFC 9325 or BCP195 and maybe mention using IKEv2/IPsec RFC 7296 with
RFC 8247/8221 as another secure transport that can be used. (I think
IKEv2/IPsec might not be used with netconf/restconf so perhaps ignore
that part)

Section 3.8 states:

         Passwords and keys may be encrypted via a symmetric key

Doesn't this move the problem? Isn't _that_ symmetric key then not
still stored in the clear?


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



I see no mention of CRLs or OCSP? Is this not commonly used with NETCONF
or RESTCONF ?

2.1.2 What about OpenPGP key types? Would it be expected some openpgp
module would update this module with a new type?

2.1.4 Why not a pkix based grouping for all pkix operations?

2.1.4.2 What about hashed passwords (eg crypt(), PBKDF2, ARGON2, SCRYPT))
and their parameters? I guess passwords here focus on the devices and their
storage? not on password types received from a human or the network for validation?
Which I would assume is the same reason we do not list PINs anywhere in the model?

Section 3.8 states:

        In order to thwart rainbow attacks, algorithms that result in
        a unique output for the same input SHOULD NOT be used. For
        instance, AES using "ECB" SHOULD NOT be used to encrypt values,
        whereas "CBC" mode is permissible since an unpredictable
        initialization vector (IV) MUST be used for each use.

I didn't find this clear. How about something like:

        To securely encrypt a password or key with a symmetric key, a
        proper block cipher mode such as an AEAD or CBC MUST be used. This
        ensures that a random IV is part of the input, which guarantees
        that the output for encrypting the same password or key still
        produces a different unpredictable ciphertext. This avoids leaking
        that some encrypted keys or passwords are the same and makes it
        much harder to pre-generate rainbow tables to brute force attack
        weak passwords. The ECB block cipher mode MUST NOT be used.


        However, comparing key strengths can be complicated

Add "of different algorithms" ? Because comparing AES128 to AES256 is not complicated :)