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. ---------------------------------------------------------------------- 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. --- 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). --- 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. --- 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. --- 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]." _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
