[SCITT] Re: draft-ietf-scitt-scrapi-09 ietf last call Secdir review

[Jonathan Geater <[e-mail]>]

Hi Alexey,

Thank you for your careful review of the document.

However I think this nit is already addressed.

You say:
“It only follows if the client maintains state about Signed Statements it submitted.”

And the draft on the line immediately below says:
“However, this relies on clients actively checking for Receipts and does not prevent the disruption itself"

Now, I appreciate there’s a subtle difference in these 2 things, especially if one considers outages at inconvenient times or clients that submit many asynchronous requests, but in all practical senses the warning is already these: you have to actively ensure you get a satisfactory result from then request you submitted. You can’t just fire and forget.

I’m not sure whether the added detail of keeping the necessary state in order to make these active checks is necessary is it? If you have a suggestion for a qualitative improvement we’d look at adopting it, but I’m just not sure if there’s actually anything to add.

Thanks,

Jon

Sent from Outlook for Mac
On 22/04/2026, 18:14, "Alexey Melnikov via Datatracker" <[e-mail]> wrote:

Document: draft-ietf-scitt-scrapi
Title: SCITT Reference APIs
Reviewer: Alexey Melnikov
Review result: Has Nits

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.