I agree that this text is worth improving. I like Martin's text slightly better, because it's a bit more specific.
Thanks, Ian On Wed, Oct 30, 2024 at 7:06 AM Martin Thomson <[email protected]> wrote: > 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 > >
