Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. When I was re-assigned to review this draft the indicated deadline was already missed by 8 months, so I don't know how relevant the review is. I reviewed the latest -20 version of the draft instead of -18, that was requested. The draft defines common YANG data types and groupings useful for cryptography. I din't try to check the YANG module itself. Issues: Shouldn't a Privacy Considerations section be added to the draft? The draft defines quite a lot of privacy-sensitive information (like certificates) with no restriction on read access (as far as I understand). Section 3.5. While I understand and support the idea, expressed in this section, I think that the way it is expressed makes it difficult to follow in practice. In general, it's not always obvious how to estimate the "strength" of the underlying secure transport. For this reason it's not clear for me how it is supposed to "compare" the "strength" of the transport with the "strength" of the keys being transported. In addition, the requirement, that "Implementations SHOULD fail the write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. I think that the better approach would be to advise using strong ciphersuites for transport protocols defined in corresponding RFCs. For example, for TLS 1.3 there are ciphersuites marked as "recommended", that were evaluated by IETF crypto community. Section 3.6: For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. Not only IV for CBC should be unique, it should be unpredictable (random or pseudo-random). I also think that lowercase "should" here must be uppercase, or even MUST. Typos, nits: Section 3.6: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD be used. s/SHOULD/SHOULD NOT For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. s/EBC/ECB s/it// I believe "okay' is a bit of slang, isn't it? Section 3.8: Since the module in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings. s/define/defines -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
