IETF Last Call Review of draft-ietf-regext-epp-quic-09
review-ietf-regext-epp-quic-09-secdir-lc-ounsworth-2026-06-15-00

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.

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.

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.

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.

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.

Operational Considerations 10.7 and 10.8 are also Security Considerations, so
should probably be copied / referenced from 11. Security Considerations.