This also looks like it should be verified to me, but I’d like the wg to check.
Francesca On 2024-03-20, 23:40, "RFC Errata System" <[email protected]> wrote: The following errata report has been submitted for RFC9000, "QUIC: A UDP-Based Multiplexed and Secure Transport". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7861 -------------------------------------- Type: Technical Reported by: Mike Bishop <[email protected]<mailto:[email protected]>> Section: 8.1.2 Original Text ------------- If a server receives a client Initial that contains an invalid Retry token but is otherwise valid... Corrected Text -------------- If a server receives a client Initial containing a valid Retry token that does not authenticate the peer address... Notes ----- Valid tokens MUST be a) integrity-protected (Section 8.1.4) and distinguishable as to purpose (Section 8.1.1), i.e. tokens from a Retry packet vs. tokens from NEW_TOKEN frames. To satisfy address validation, they should enable the server to verify the client's transport address. This text does not specify which form of invalidity is being discussed -- failure of integrity protection or a mismatch between the contents of the token and the client's address. Applying this text to all "invalid" tokens which appear to be Retry tokens does not allow for the scenario where the token was generated by another server / another QUIC implementation and is in fact unreadable. Such tokens, even if they appear to be Retry tokens, are supposed to be handled by the requirements in 8.1.3, i.e. ignore the token and handle the packet as if no token were present. This section should be scoped only to tokens which are correctly formatted and readable by the server, but whose contents are not sufficient to prove the client's transport address is valid. Otherwise, the determination that the token is a Retry token cannot be trusted. (This discrepancy appears in a multi-CDN context, where tokens generated by one CDN will sometimes be received by a different CDN; if these tokens appear to be "invalid Retry tokens", the connection is closed when the token should simply be ignored.) Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC9000 (draft-ietf-quic-transport-34) -------------------------------------- Title : QUIC: A UDP-Based Multiplexed and Secure Transport Publication Date : May 2021 Author(s) : J. Iyengar, Ed., M. Thomson, Ed. Category : PROPOSED STANDARD Source : QUIC Stream : IETF Verifying Party : IESG
