Document: draft-ietf-httpbis-optimistic-upgrade Title: Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am the assigned int-dir reviewer for this draft. These comments were written with the intent of improving the Internet area aspects of the IETF drafts. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For background on int-dir, please see the FAQ at https://wiki.ietf.org/en/group/intdir. This document discusses security risks of optimistic protocol transitions in HTTP/1.1, where a client begins using a new protocol before receiving the server’s response confirming the transition. The risks include: - Request smuggling: An attacker could send a request that would normally be rejected, leveraging the client’s premature protocol switch. - Parser exploits: A server that does not recognize the transition might misinterpret the request, exposing vulnerabilities. To prevent these risk, this document makes several recommendations for both the client and the server. Basically, it clearly prohibits the optimistic transition. As a result, it updates RFCs 9112 and 9298. This is a well-written document, easy to understand for those not very familiar with the relevant protocols such as this reviewer. In particular, I've not found any issues from the int-area point of view. I have one possible editorial issue: in section 2, the draft states: However, because of the possibility of rejection, the converse is not true: a client cannot necessarily begin using a new protocol merely because it has finished sending the corresponding request message. It was difficult for me to understand. Specifically, - The term “the converse” is ambiguous. - The role of “because of the possibility of rejection” is unclear. Based on context, I interpreted the intended meaning as: A client is allowed to begin using a new protocol once it has finished sending the corresponding request message, even if the request can be rejected by the server. At least to me, the latter is much easier to understand. If this interpretation is incorrect, the original text may need clarification in case I'm not the only confused reader. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
