RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021

Errata ID: 7861
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Mike Bishop
Date Reported: 2024-03-20

Section 8.1.2 says:

If a server receives a client Initial that contains an invalid Retry
token but is otherwise valid...

It should say:

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.)

Report New Errata