Hello Mahesh,
Thanks for your kind review and nice suggestions.
Some comments inline below.
> 2026年6月28日 04:42，Mahesh Jethanandani via Datatracker <[email protected]> 写道：
>
> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-regext-epp-quic-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 8.8, 0-RTT and Session Resumption:
>
> 472 > Using 0-RTT for EoQ allows clients to establish connections and
> 473 > initiate EPP transactions without round-trip delay, enabling servers
> 474 > to use shorter idle timers and reduce connection overhead. Session
> 475 > resumption and 0-RTT introduce privacy and replay risks. EoQ
> 476 > implementations SHOULD follow [RFC8446] and [RFC9001] guidance to
> 477 > balance performance and risk mitigation. Failure to do so increases
> 478 > privacy exposure and replay attack risks.
>
> RFC 9001 Section 5.6 states: "An application protocol that uses QUIC
> MUST include a profile that defines acceptable use of 0-RTT; otherwise,
> 0-RTT can only be used to carry QUIC frames that do not carry
> application data." EoQ defines no such profile. Directing
> implementers to "SHOULD follow [RFC8446] and [RFC9001] guidance" is
> not a substitute for defining that profile, and this document therefore
> does not satisfy the MUST from RFC 9001.
>
> The absence is made more serious by the text above asserting that 0-RTT
> allows clients to "initiate EPP transactions." If EoQ defines no
> profile permitting EPP application data in 0-RTT, RFC 9001 prohibits
> exactly that use. The text and the RFC 9001 requirement are directly
> contradictory. EPP commands, including <login> itself, are
> not safe to replay without application-layer protections that this
> document does not specify.
>
> In my view, this section must be revised.
> At a minimum, the document
> should either:
>
> (a) explicitly prohibit EPP application data (including <login>) from
> being carried in 0-RTT data, specifying only the EoQ Connection Start
> Packet as a candidate for 0-RTT, or
>
> (b) define a specific 0-RTT profile — including which EPP messages
> may be included, what replay mitigations are required, and how session
> authentication
> state interacts with resumed sessions — thereby satisfying the RFC 9001
> MUST.
>
>
Yaojk:
Thanks. I think that (b) is fine.
How about？
Old:
“
Using 0-RTT for EoQ allows clients to establish connections and initiate EPP
transactions without round-trip delay,
enabling servers to use shorter idle timers and reduce connection overhead.
Session resumption and 0-RTT introduce privacy and replay risks.
EoQ implementations SHOULD follow [RFC8446] and [RFC9001] guidance to balance
performance and risk mitigation.
Failure to do so increases privacy exposure and replay attack risks.
"
New:
“
Using 0-RTT for EoQ allows clients to establish connections and initiate EPP
transactions without round-trip delay,
enabling servers to use shorter idle timers and reduce connection overhead.
Session resumption and 0-RTT introduce privacy and replay risks.
EPP commands fall into three categories: session management, queries and
transform commands.
EPP query commands perform read-only object information retrieval operations.
Only read-only EPP query commands MAY be carried in 0-RTT STREAM frames; all
other EPP commands MUST NOT use 0-RTT.
Clients SHOULD use resumption tickets only once specified in [RFC8446].
Servers SHOULD issue session resumption tickets with a sufficiently long
lifetime (e.g., 6 hours).
Servers SHOULD implement the anti-replay mechanisms specified in Section 8 of
[RFC8446].
EoQ implementations SHOULD follow [RFC8446] and [RFC9001] guidance to balance
performance and risk mitigation.
Failure to do so increases privacy exposure and replay attack risks.
"
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 5, Data Unit Format:
>
> 305 > The EPP data unit contains two fields: a 32-bit header that describes
> 306 > the total length of the data unit, and the EPP XML instance. The
> 307 > length of the EPP XML instance is determined by subtracting four
> 308 > octets from the total length of the data unit. A receiver must
> 309 > successfully read that many octets to retrieve the complete EPP XML
> 310 > instance before processing the EPP message.
>
> The 32-bit Total Length field permits a declared length of up to
> approximately 4 GB. The SECDIR review (thanks, Mike) against -09 raised this
> concern.
> RFC 5734 is equally silent on length-field bounds checking for the
> identical framing it defines. In my opinion, the Security
> Considerations section should recommend that
> implementations validate the declared length against a locally
> configured maximum before allocating memory or attempting to read the
> declared number of octets. Without such guidance, a single crafted
> packet with an oversized length field can exhaust a receiver's memory.
> I would suggest adding a sentence to Section 11 to this effect.
>
> ---
Yaojk:
Agree.
The following text will be added to the section 11.
“
The 32-bit total length field defined in Section 5 allows a declared payload
size up to approximately 4 gigabytes.
Implementations MUST validate the advertised total length against a locally
configured maximum frame size limit
before allocating memory or attempting to read the full frame. Without this
check, an attacker could send a crafted
frame with an excessively large length value to exhaust receiver memory and
trigger a denial-of-service condition.
"
>
> Section 6, EoQ Connection Start Packet, error handling:
>
> 337 > Absent processing errors or local policy, the server accepts the
> 338 > QUIC stream, reads the EoQ Connection Start Packet, and returns
> 339 > the EPP <greeting> to the client on same QUIC stream.
>
> The document specifies that a valid EoQ Connection Start Packet MUST be
> exactly 24 octets containing the literal string "EoQ Connection Start"
> (Section 6). However, it does not specify what the server MUST or
> SHOULD do if it receives a stream-opening packet that does not conform
> to this format — for example, if the Total Length field is not 24, or
> if the payload does not match the expected constant. Section 7
> addresses error handling for malformed EPP commands, but not for a
> malformed EoQ Connection Start Packet. In my opinion, the document
> should specify the required server behavior in this case (e.g., close
> the QUIC stream, with or without returning an error).
>
> ---
Yaojk:
Agree.
The following text will be added to the section 6.
"
If the EoQ Connection Start Packet the server receives is not valid — such as
when the total length is not exactly 24 octets,
the server MUST close that QUIC stream. The server MAY return an error
indication prior to closing the stream.
"
>
> Section 4, Message Exchange, stream limiting:
>
> 229 > A server SHOULD limit a client to a maximum number of QUIC
> 230 > streams per QUIC connection based on server capabilities and
> 231 > operational load. Absent such limit, a server may be subject to
> 232 > overload and resource exhaustion.
>
> RFC 9000 Section 4.6 defines the normative QUIC mechanism for this:
> servers use the max_streams transport parameter and MAX_STREAMS frames
> to limit the number of streams a peer may open, and endpoints MUST NOT
> exceed the limit set by their peer. In my opinion, this section should
> reference that mechanism explicitly, so that implementers understand
> both how to enforce the limit and the QUIC-level error (STREAM_LIMIT_ERROR)
> that results from a client exceeding it. The TSV-ART review against
> -09 also noted this gap.
>
> ---
Agree.
Old:
“
A server SHOULD limit a client to a maximum number of QUIC streams per QUIC
connection based on server capabilities
and operational load. Absent such limit, a server may be subject to overload
and resource exhaustion.
"
New:
“
A server SHOULD limit a client to a maximum number of QUIC streams per QUIC
connection based on server capabilities
and operational load. Absent such limit, a server may be subject to overload
and resource exhaustion.
Section 4.6 of [RFC9000] specifies this situation.
"
>
> Section 3, Session Management, max_idle_timeout:
>
> 207 > The max_idle_timeout transport parameter defined in
> 208 > Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value by the
> 209 > client or server. Once the last QUIC stream for a QUIC connection is
> 210 > closed, the server MAY end the QUIC connection immediately.
>
> I understand the intent. However, a consequence of setting max_idle_timeout
> to 0 is that a
> QUIC connection with no open streams can remain open indefinitely.
> The server is permitted but not required to close the connection when
> the last stream closes. In my opinion, the document should say
> something about the expected behavior in this state, perhaps elevating
> the "MAY end the QUIC connection immediately" to SHOULD, to help
> operators avoid accumulating zombie connections.
>
> ---
Agree.
Old:
“
The max_idle_timeout transport parameter defined in
Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value by the
client or server. Once the last QUIC stream for a QUIC connection is
closed, the server MAY end the QUIC connection immediately.
"
New:
"
The max_idle_timeout transport parameter defined in
Section 18.2 of [RFC9000] MUST NOT be set to a non-zero value by the
client or server. Once the last QUIC stream for a QUIC connection is
closed, the server MAY either immediately end the QUIC connection
or retain the connection open in accordance with local configuration and
operational policy.
"
>
> Section 9.2, Registration of Port Number:
>
> 511 > This document requests IANA to update that entry so that it is
> 512 > reassigned to EPP and add a reference to this document.
>
> The phrase "reassigned to EPP" is confusing because port 700/UDP is
> already assigned to the EPP service (service name "epp"). What the
> document is requesting is an update to the Description field (from the
> current generic EPP text to "EPP run over QUIC") and the addition of
> this RFC as an additional reference alongside [RFC5734].
> The IANA request should be stated precisely: for example,
> "This document requests IANA to update the Description field of the
> EPP UDP/700 entry to 'EPP run over QUIC' and to add this document as
> an additional Reference alongside [RFC5734]."
>
>
>
Agree.
Old:
“
This document requests IANA to update that entry so that it is reassigned to
EPP and add a reference to this document.
"
New:
"
This document requests IANA to update the description field of the EPP UDP/700
entry
to "EPP run over QUIC" and add this document as an additional Reference
alongside [RFC5734].
"
Thanks a lot.
Jiankang Yao
> _______________________________________________
> regext mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
