Ballot for draft-ietf-anima-rfc8366bis
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Needs 2 more YES or NO OBJECTION positions to pass.
I found this draft to be extremely difficult to review, as a result I have put the bulk of my comments in the comment section, not because I don't believe they are not important, but because there are many of them. I do believe interoperability is unlikely given the current construction of this draft. Section 7, COSE: It appears that cBRSKI relies on DTLS for cipher suites, which means that there is a PQ migration path in the case when signing utilizes COSE. The ML-DSA draft for (D)TLS is nearly in the editor's queue. Section 7, CMS: While this draft references RFC 8366, in fact CMS has been updated to include PQ signature algorithms via RFC9882. If a composite algorithm is more useful, then that draft is in process. One of these should be considered. Section 8, para 8, 9 and 10: I support Roman's Discuss, especially since the signatures being described in the draft are likely long lived signatures. Section 8, para 9: I also support Roman's discuss wrt the fact that it appears that there is no MTI. Given the nature of this technology, I suspect that an MTI is necessary.
If the goal is to enable interoperability, then this draft needs to be cleaned up to be clear, concise, and logical. Currently, it appears to be a mishmash of terminology and loose specifications. I will give some examples below where I think it is unclear, but I can't claim to be complete in my review: Section 1, para 4: I'm confused by this statement: 'the Pledge can then use the resulting anchor to authenticate other actors who are part of the network'. Is this because other 'actors' hold the private key for the trust anchor? Is it because other 'actors' have certificates that are signed by the trust anchor? Does the Pledge hold a key and certificate certified by the trust anchor? Section 1, para 7 and 8: These two paragraph does not flow from the previous paragraphs which are discussing trust anchors, vouchers and pledges. Perhaps a sub section would help. Section 1, para 9 and 10: yet another jump. This time, it might make sense to move these before para 7 and 8. When a specification jumps around from topic to topic, it is difficult to see how any implementer will be able to follow - severely impacting interoperability. Section 2, Bootstrapping and onboarding: If bootstrapping is being deprecated, merely state that and point to the onboarding definition. One can only hope that there is a good reason for this terminology shift. Section 2, Imprinting: This is a lovely idea, but how does it mesh with what was discussed in Section 1 where the terms Voucher, Pledge, and trust anchors. Would the term 'Trust Anchor' be more suitable? Section 2, Join Registrar: How important is the phrase 'perhaps autonomically'? And if it is referred to as 'just Registrar', then why not define 'Registrar'? Section 2, Malicious Registrar: What is the entity seeking to do, presumably to the Pledge? Section 2: I'm not sure the terminology could be more confusing. For example: "Voucher: a Voucher Artifact, not a Voucher Request...", while "Voucher Request: a signed artifact...." But while a Voucher Request is a signed artifact (does lower case make it different?), it is not a Voucher. I don't even know what to suggest. Section 4, Assertion Basis: what is 'measured boot'? (I know what 'secure boot' is) Section 4: It is really unclear exactly how the use of nonces or time limits blocks a malicious registrar. This is especially true if the nonces are transmitted in the clear. Section 5: Where is the list of changes? Section 5.1: What is the purpose of this section? A clear and concise list of changes would be more useful. Section 8, EcDSA: https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list suggests that this should be ECDSA (which is also the only way I've ever seen it). Section 9.1: 'manufacturer-private?'. Does this imply the manufacturer's private key? Surely this isn't sent to anyone. Section 10.1, para 2: 'Revocation artifact'? Like an OCSP response showing that the current key/cert pair is still valid? OCSP is specified in RFC 6960. Section 10.1, para 3: Updating a short-lived certificate requires the same care as the initial certification. It is more than merely 'updates the Voucher's validity period'. One needs to ensure that the entity that holds the private key still possesses it, and hasn't disclosed it. Section 11.1, para 2: Devices with no understanding of time cannot possibly verify that the 'expires-on' field has not yet passed. Section 11.2: Why not MUST? What are the circumstances in which is it ok to not store that private key in an HSM? Section 11.4: For sensitive data fields which are distributed, I would expect these structures to be encrypted as well as signed. Nonces and other private values should not be distributed in the clear (or merely signed). I would have preferred to see the carefully constructed paragraph which is normally standard in Yang specifications.
# Éric Vyncke INT AD comments for draft-ietf-anima-rfc8366bis-34 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Section 8.3 Perhaps due to my lack of knowledge about YANG, but what is the expected behavior when both pinned-domain-cert and pinned-domain-pubk (or pinned-domain-pubk-sha256) are present but are inconsistent ? (e.g., the SHA256 is not correct) ? There are comments about "Choice" surrounding this part of the YANG module, but it is probably only for human beings. ### Section 11.4 Why not a MUST in `When privacy is important, the CMS signed-data content type SHOULD be encrypted,` ? Else, provide additional guidance per IESG statement: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (even if semi obvious).
## COMMENTS (non-blocking) ### YANG errors ? The data tracker status page indicates 4 errors and 3 warnings, the shepherd's write-up is silent about these errors. ### Other DISCUSS I second Roman Danyliw's DISCUSS about post-quantum in section 8 (and also the use of SHOULD without any additional guidance) and use of BCP14 in the IANA considerations. ### Short and long lifetime Section 10.1 and others mention short lifetime but without giving any guidance to the readers/implementers about the duration of "short lifetime".
I support Ketan's DISCUSS regarding YANG validation. It would be good to get to the bottom of this, and to fix the tooling if the tooling is in fact in error.
Thanks to the authors and the WG for their work on this document. Also thanks for the discussion and addressing my concerns with the document updates.
Thanks for addressing my DISCUSS feedback for -34.
(updated ballot for text introduced in -35)
** Section 13.5 (formerly 12.5)
Extension name strings for IETF process (standards track,
experimental, IRTF) documents are single words, given by the YANG
Module Name: They do not contain dots.
-- Extension names strings for “IETF processes” are defined as “standards track, experimental, IRTF”, but “IETF processes” don’t govern the IRTF.
-- Is this text saying that this naming convention doesn’t apply to IETF stream, informational status documents?
** Section 13.5 (formerly 12.5)
* There are no choices in the extension names (for standards track
extensions) which is always the YANG module name), or SID value
(which is from another IANA process).
* For non-standards track extensions, the Designated Expert should
review the provided document for clarity of purpose. The
stability of the reference may be of concern.
-- The earlier text says that experimental and IRTF documents there is also no choice for extension names, but here the text says the guidance only applies to standards track.
-- What would IETF stream non-standards documents get a DE review for clarity of purpose, but not an IETF stream standards track document?
I support all four active DISCUSS ballots and share concerns around the document's current fitness, but I do not have additional DISCUSS worthy concerns independent of those, so I will stick with No Objection. Minor point: Section 8.3 explains why the choice mechanism was commented out. Why is it still there at all then? I would encourage the authors to consider the utility of having that there if its use (uncommenting it) isn't recommended and if the prose within Section 8.3 to explain the lessons learned is sufficient.