IETF Last Call Review of draft-ietf-scitt-scrapi-09
review-ietf-scitt-scrapi-09-secdir-lc-melnikov-2026-04-22-00
| Request | Review of | draft-ietf-scitt-scrapi-07 |
|---|---|---|
| Requested revision | 07 (document currently at 09) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2026-04-10 | |
| Requested | 2026-02-25 | |
| Requested by | Jon Geater | |
| Authors | Henk Birkholz , Jon Geater , Antoine Delignat-Lavaud | |
| I-D last updated | 2026-04-26 (Latest revision 2026-04-21) | |
| Completed reviews |
Httpdir Early review of -01
by Darrel Miller
(diff)
Secdir IETF Last Call review of -09 by Alexey Melnikov Opsdir IETF Last Call review of -08 by Nick Buraglio (diff) Genart IETF Last Call review of -08 by Gyan Mishra (diff) Secdir IETF Last Call review of -08 by Valery Smyslov (diff) |
|
| Comments |
I hope a one-month deadline isn't too aggressive for the reviewer rotations. It's quite arbitrary so do push back if you can't get it done by then. We're just trying to move things along. |
|
| Assignment | Reviewer | Alexey Melnikov |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-scitt-scrapi by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/0QKx9Wj7GIEiZpaG7znLzTJ-EBQ | |
| Reviewed revision | 09 | |
| Result | Has nits | |
| Completed | 2026-04-22 |
review-ietf-scitt-scrapi-09-secdir-lc-melnikov-2026-04-22-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. I was the originally assigned SecDir reviewer who missed the deadline, so Valery Smyslov provided a good SecDir review. I read -09 and also checked changes between -08 and -09 which addressed most of Valery's comments. I think the latest version has improved on Security Considerations. I have only a small thing on the latest version. Section on the Denial of Service attacks (4.4.1.1) has now the following text: The impact of DoS attacks can be detected by a client checking that the Transparency Service has registered any submitted Signed Statement and returned a Receipt. I agree so far. Since verification of Receipts does not require the involvement of the Transparency Service, If you mean that clients can verify digital signatures on Receipts, I agree. a DoS attack cannot cause the silent loss of a registration. I am not entirely sure this follows. It only follows if the client maintains state about Signed Statements it submitted. Is it worth clarifying? However, this relies on clients actively checking for Receipts and does not prevent the disruption itself.