Mike, Thank you for the review. I provide responses to your feedback embedded below prefixed with "JG-". Overall, we will include some guidance on the packet framing operational practice based on the experience with implementing the same EPP over TPC (EoT) packet framing in RFC 5734.
Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/15/26, 3:44 PM, "Mike Ounsworth via Datatracker" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Document: draft-ietf-regext-epp-quic Title: Extensible Provisioning Protocol (EPP) Transport over QUIC Reviewer: Mike Ounsworth Review result: Has Issues 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 that I think the new packet framing format defined in section 5, while simple, may require some more thinking about whether some additional error handling can be specified that would make it more robust to accidental or malicious mismatching of the length field to the actual length of the payload. Detailed comments: SecDir review for draft-ietf-regext-epp-quic-09 Section 5: 2^32 bytes (4 gb) can be quite a large network payload, and could lead to resource exhaustion issues. Perhaps you want to recommend that implementations keep a max EPP Data Unit size that they are willing to accept; ie check the length header, make sure it's under the configured limit, then proceed to reading the EPP XML payload. JG-This is good feedback. The packet framing is reused from EPP over TCP (EoT) in RFC 5734 and in practice servers do include a maximum length validation prior to attempting to read the packet. No guidance is provided in RFC 5734, but I agree that guidance is warranted based on EoT operational practice. The maximum length is up to server policy based on the set of EPP extensions supported by the server. The Verisign EPP SDK (https://www.verisign.com/resources/registrar-resources/epp-sdk/) sets the maximum length to 355000 bytes that applies to both the maximum packet size accepted by the client (SDK client) and the server (SDK stub server), where a value of 10000 bytes is reasonable for a server, since the commands are historically much smaller than the responses. We want the same EPP packet framing to occur across the supported transports (EoT or EoQ). You're specifying here a new Length-Value data encoding, so we need to ask what happens if the Length is set incorrectly (either accidentally or maliciously), and think about how to make parsers robust to that. JG-If the Length is incorrectly set, the server will drop the connection (QUIC stream in the case of EoQ). Also, what happens if the Total Length declared in the header does not match the actual EPP XML? This is the sort of thing that lead to the openssl heartbleed vulnerability, so if section 5 can specify some error handling that would make this more robust to maliciously or accidentally incorrect length fields, that would be good. JG-If the Total Length declared doesn't match the actual EPP XML, the server will have a partial XML packet to validation, which will fail XML schema validation and result in a 2001 "Command syntax error" if the XML parser can make any sense of it. If the packet is not recognizable it would result in a drop of the connection (QUIC stream in the case of EoQ). The connection could be closed in attempting to read the next packet, since the network header will be standard characters and likely result in a length higher than the maximum size based on reading. I have seen this in practice with EoT, where the connection is dropped if the packet framing is incorrect. The most likely mistake is not removing the 32-bits of the header from the length when readying the XML. For a length tag shorter than the actual payload; in the accidental case you'll end up with a busted unparsable XML document, and probably a messed up QUIC stream since there'll be a bunch of extra junk in there that's not accounted for. Probably this is fatal to the connection and it should just be closed? Is there a malicious case? I guess that would be to construct an OWASP Top 10 Request Smuggling payload where the XML payload is a properly closed XML document followed by the bytes of a properly-encoded new EPP message and the length field points at the end of the XML doc. From the protocol's perspective, this is probably just normal stream data and not a problem; so maybe it's only worth a note that in order to protect against request smuggling attacks, implementations SHOULD be careful to actually count the byte length of the payload they have been given instead of trusting an application to correctly give them both the payload and its length. JG-Correct, by providing guidance in validating the maximum length this should be covered. A server (and client) should implement a maximum length validation, attempt to read the packet, and if the packet is malformed the connection should be dropped. Receiving a full EPP packet with XML schema validation errors does not apply here, since it should result in a 2001 "Command syntax error". To detect a length field longer than the actual payload, is it possible to specify that if the EPP XML parser hits the end of the XML document before the end of the declared length, should it refuse to process it with an XML parser and instead kill the connection? That would have the net effect that buggy implementations would not be tolerated and would hopefully get caught before making it to prod. The packet framing and applying the maximum packet size is done before passing the packet onto the XML parser. Incorrect packet framing should be caught ahead of the XML parse and fast fail by closing the connection (QUIC stream in the case of EoQ). Operational Considerations 10.7 and 10.8 are also Security Considerations, so should probably be copied / referenced from 11. Security Considerations. JG- Thanks, we'll handle this by reference. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
