[secdir] Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Secdir review

[Ionut Mihalcea <[e-mail]>]

Hi Marten,

Thank you for addressing the comments! I've just looked through the PRs and all seems good to me.

Cheers,
Ionut

From: Marten Seemann <[e-mail]>
Date: Saturday, 8 August 2026 at 07:49
To: Ionut Mihalcea <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Secdir review

Thank you for the review!

> At the end of sec. 1: "application protocols continue to treat this stream
function as an abrupt termination". Clarifying question: is this in the sense
that application protocol can expect no new data to be sent over this stream?
Because "abrupt termination" doesn't seem representative of the new behaviour
overall.

It is abrupt termination in the sense that it tells the application that the transfer was not successful. For example, when downloading a file, you might treat a FIN as "all the bytes I received constitute the entirety of this file" vs. a RESET_STREAM (or RESET_STREAM_AT) as "parts of the file were transferred, but what I received is not the complete file".

https://github.com/quicwg/reliable-stream-reset/pull/94 should make this clearer.

> In sec. 5: "A RESET_STREAM_AT frame with this value is logically equivalent to
a RESET_STREAM frame". I'm not sure this is consistent with the state machine
transitions described in sec. 5.3. For example, with RESET_STREAM the state
machine is not expected to go from Recv through Size Known.

I think it is, given the following sentence in the draft:
> Once all data up to the smallest Reliable Size have been received, it enters the "Data Recvd" state.

...which in the case of a Reliable Size of 0 is immediate. That said, I think we can improve the wording a bit: https://github.com/quicwg/reliable-stream-reset/pull/92

> In sec 5.3: "Conversely, if bytes below that offset still need to be sent or
acknowledged, the transition might take multiple network roundtrips and *might
require additional flow control credit issued by the receiver*." (emphasis
mine) It seems impossible to reach the state described at the end, requiring
additional flow control credit. In sec. 4 you note that "An endpoint MUST NOT
send a RESET_STREAM_AT frame that exceeds the largest maximum stream data value
advertised by the receiver for the stream, or that violates the receiver's
maximum data limit." Coupled with "If the Reliable Size is larger than the
Final Size, the receiver MUST close the connection", Reliable Size must always
be fully accounted for in the current flow control credit.

> In sec. 5.3: "This might require the receiver to issue additional flow control
credit." - identical reasoning to above.

The intention of this section was to say that if your application's requirement is to send a stream header of N bytes, you're not able to send RESET_STREAM_AT with Reliable Size N before you've received flow control credit for at least N. I opened a PR: https://github.com/quicwg/reliable-stream-reset/pull/93



On Wed, 29 Jul 2026 at 23:47, Ionuț Mihalcea via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Document: draft-ietf-quic-reliable-stream-reset
Title: QUIC Stream Resets with Partial Delivery
Reviewer: Ionuț Mihalcea
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.

The summary of the review is Almost Ready.

The draft defines a new frame for QUIC, allowing senders to reset a stream with
the promise of reliable delivery for a given amount of data on said stream.

The document is well written and seems comprehensive in integrating the new
mechanism in the QUIC stream management machinery. I noticed a few
inconsistencies (which might be due to my lack of expertise with QUIC),
described below.

At the end of sec. 1: "application protocols continue to treat this stream
function as an abrupt termination". Clarifying question: is this in the sense
that application protocol can expect no new data to be sent over this stream?
Because "abrupt termination" doesn't seem representative of the new behaviour
overall.

In sec. 5: "A RESET_STREAM_AT frame with this value is logically equivalent to
a RESET_STREAM frame". I'm not sure this is consistent with the state machine
transitions described in sec. 5.3. For example, with RESET_STREAM the state
machine is not expected to go from Recv through Size Known.

In sec 5.3: "Conversely, if bytes below that offset still need to be sent or
acknowledged, the transition might take multiple network roundtrips and *might
require additional flow control credit issued by the receiver*." (emphasis
mine) It seems impossible to reach the state described at the end, requiring
additional flow control credit. In sec. 4 you note that "An endpoint MUST NOT
send a RESET_STREAM_AT frame that exceeds the largest maximum stream data value
advertised by the receiver for the stream, or that violates the receiver's
maximum data limit." Coupled with "If the Reliable Size is larger than the
Final Size, the receiver MUST close the connection", Reliable Size must always
be fully accounted for in the current flow control credit.

In sec. 5.3: "This might require the receiver to issue additional flow control
credit." - identical reasoning to above.

Thanks!