Yeah, this is right. Mostly. The problem is that the server needs to detect the token as being a Retry token. This might be done through a single public bit, in which case the error condition could be definitively identified, even if the token is damaged. (There is no harm in making the Retry/NEW_TOKEN distinction predictable/visible, which greatly simplifies the implementation.)
I would maybe suggest: If a server receives a client Initial that contains a token that is identifiable as a Retry token, but the token is invalid or does not otherwise validate the client's address, it knows ... Note that in the multi-CDN case that Mike refers to, this condition of "identifiable as a Retry token" likely cannot be attained with special coordination. In the (likely) absence of coordination this effectively reduces this to Mike's proposed text. On Wed, Oct 30, 2024, at 20:44, Francesca Palombini wrote: > 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]> > > 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
