Early Review of draft-ietf-opsawg-yang-provenance-04
review-ietf-opsawg-yang-provenance-04-secdir-early-roca-2026-04-03-00
| Request | Review of | draft-ietf-opsawg-yang-provenance |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | Early Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-04-04 | |
| Requested | 2026-03-18 | |
| Requested by | Joe Clarke | |
| Authors | Diego Lopez , Antonio Pastor , Alex Huang Feng , Ana Méndez Pérez , Henk Birkholz | |
| I-D last updated | 2026-05-29 (Latest revision 2026-05-29) | |
| Completed reviews |
Yangdoctors Early review of -05
by Jan Lindblad
Secdir Early review of -04 by Vincent Roca (diff) |
|
| Comments |
The authors have been busy implementing this draft in IETF hackathons and have reached a point where they would like a "deep" review by SEC DIR and YANG Doctors. Thanks. |
|
| Assignment | Reviewer | Vincent Roca |
| State | Completed | |
| Request | Early review on draft-ietf-opsawg-yang-provenance by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/CLGTPR98L8-eSlyRc2ZYQCl1ABc | |
| Reviewed revision | 04 (document currently at 05) | |
| Result | Not ready | |
| Completed | 2026-04-03 |
review-ietf-opsawg-yang-provenance-04-secdir-early-roca-2026-04-03-00
Hello, 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. Summary: not ready Main comments: -- Globally speaking, the problem is very well introduced. -- The Security section basically explains that the link between a public key and the entity owning the associated private key should be secured by other means (e.g., certificate, PKI), which is fine. But I'd like to see somewhere an explicit threat model, explaining what are the capabilities of a potential attacker. Doing so also clarifies what is NOT protected by the proposal in case of a more powerful attacker. -- Section 2: The second part of sentence: "and where it has moved from to where it is presently" is unclear. There is no validation of the entire path followed by data **by default**, since the addition of a signature only authenticates the origin. If I understand correctly, the "recursively applied" suggestion that follows to provide some kind of "path verification" is not detailed anywhere in this document. It is not a guaranty that applies by default and it should not be included in the definition of "data provenance" IMHO. Detail: -- The abstract could provide the meaning of the COSE acronym. Regards, Vincent