IETF Last Call Review of draft-ietf-rats-network-device-subscription-11
review-ietf-rats-network-device-subscription-11-secdir-lc-salowey-2026-04-12-00
| Request | Review of | draft-ietf-rats-network-device-subscription |
|---|---|---|
| Requested revision | No specific revision (document currently at 12) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-04-13 | |
| Requested | 2026-03-30 | |
| Authors | Henk Birkholz , Eric Voit , Wei Pan | |
| I-D last updated | 2026-05-28 (Latest revision 2026-05-26) | |
| Completed reviews |
Yangdoctors Early review of -02
by Jürgen Schönwälder
(diff)
Opsdir IETF Last Call review of -11 by Sheng Jiang (diff) Genart IETF Last Call review of -11 by Mallory Knodel (diff) Secdir IETF Last Call review of -11 by Joseph A. Salowey (diff) |
|
| Assignment | Reviewer | Joseph A. Salowey |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-rats-network-device-subscription by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/-cHHyRToDQblHf2ZcCchm_oLoBI | |
| Reviewed revision | 11 (document currently at 12) | |
| Result | Has nits | |
| Completed | 2026-04-12 |
review-ietf-rats-network-device-subscription-11-secdir-lc-salowey-2026-04-12-00
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. The summary of the review is the document is ready. I do agree with the Genart review by Mallory Knodel that the security considerations could be more readable, especially since more of the security considerations are by reference to other documents. I do have a question on the nonces: Section 3.1.1 Says the nonce can be used more than once. This seems counterintuitive. Are there any recommended bounds on nonce reuse and how would selecting these bounds affect the security properties? This seems more relevant in the TPM 1.2 case as the clock values may be signed in the TPM 2 case, but I am unsure if this is the case.