[Technical Errata Reported] RFC9000 (7861)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 20 March 2024 22:40 UTC

To: jri.ietf@gmail.com, mt@lowentropy.net, quic-ads@ietf.org, matt.joras@gmail.com, lucas@lucaspardue.com
Subject: [Technical Errata Reported] RFC9000 (7861)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mbishop@evequefou.be, quic@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240320224042.8061E1D51@rfcpa.amsl.com>
Date: Wed, 20 Mar 2024 15:40:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/h6pW144UDQ35kgF3hLwH0_tLkQ8>
Precedence: list

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 <mbishop@evequefou.be>

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

[Technical Errata Reported] RFC9000 (7861) RFC Errata System