Skip to main content

IETF Last Call Review of draft-ietf-scitt-scrapi-08
review-ietf-scitt-scrapi-08-secdir-lc-smyslov-2026-04-14-00

Request Review of draft-ietf-scitt-scrapi
Requested revision No specific revision (document currently at 09)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-04-13
Requested 2026-03-30
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)
Assignment Reviewer Valery Smyslov
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/dpeGoEMkzIJgQjMxpaWR2EQsPwI
Reviewed revision 08 (document currently at 09)
Result Has issues
Completed 2026-04-14
review-ietf-scitt-scrapi-08-secdir-lc-smyslov-2026-04-14-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 review assignment came on 13 April with a deadline for review set to the
same date, so I have had 0 days to complete the review. Thus I only quickly
read the document through and thus might have missed something.

The document defined REST API that supports SCITT architecture.

Issues.
1. Section 2
   In my opinion, Section 2 "Authentication" is misplaced. I'm a bit surprised
   to see this text as a dedicated section, I believe it must be part os the
   "Security Considerations" section, which discusses the general scope.
2. Section 5.3.1.1
   The text first states that "denial of service attacks are very hard to
   defend against completely" (the statement I agree with) and then "In
   principle DoS attacks are easily mitigated...". It is not clear for me how
   the described mitigation works - it relies on a behavious of a honest
   client, while DoS attacks on Transparency Service will be performed by
   malicious clients. Am I missing something?
3. Section 5.3.1.4
   On message insertion attack: "Transparency Services MAY also implement
   additional protections such as anomaly detection or rate limiting in order
   to mitigate the impact of any breach." It is not clear for me how "rate
   limiting" can help in case of message insertion attack.
3. Section 5.3.2.1
   I don't think the text "If the semantic content of the payload are
   time-dependent and susceptible to replay attacks in this way then timestamps
   MAY be added to the protected header signed by the Issuer." provides
   adequate guidance. For me this reads as "if this is a problem, you are free
   add timestamps (or not to add them)". I think that MUST is more appropriate
   here.

Nits.
1. It is better to expand "SCITT", "SCRAPI" on first use.
2. Section 5.3.1.1
   In the text "Beyond this, implementers of Transparency Services MUST
   implement general good practice around network attacks, flooding, rate
   limiting etc." I think that "flooding" is an example of an attack and "rate
   limiting" is an example of defense. Can this sentence be rephrased to
   clearly separate attacks from defense practices?