Hi Mahesh, Does this new version look good for you?
The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-quic-12 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-quic-12 Thanks a lot! Jiankng Yao > 2026年7月4日 20:28，Jiankang Yao <[email protected]> 写道： > > 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]
