Résumé

  • NEW_TOKEN est un justificatif émis par le serveur pour valider une adresse lors d’une connexion QUIC ultérieure; il ne se confond pas avec Retry.
  • Une validation réussie fournit une preuve limitée sur l’adresse source selon la politique du serveur, non l’identité d’un client récurrent.
  • Les journaux doivent séparer validation du jeton, authentification de la poignée de main, identité applicative, autorisation et résultat.

Le tableau de bord d’exploitation montre un Initial contenant un jeton et l’étiquette « client récurrent ». Cette conclusion semble pratique : NEW_TOKEN peut éviter un aller-retour supplémentaire de validation d’adresse. Elle dépasse pourtant la preuve disponible. La question réellement traitée est plus étroite : le serveur peut-il accepter ce jeton comme indice suffisant d’un lien entre l’adresse source et la connexion qui l’a reçu ?

Pendant une connexion, le serveur peut envoyer des octets opaques dans une trame NEW_TOKEN. Le client peut les placer dans les paquets Initial d’une connexion ultérieure. Il s’agit donc d’un justificatif destiné à une future connexion. Retry a une autre fonction : il est utilisé immédiatement pour la tentative en cours et ne doit pas être transporté vers des connexions suivantes. NEW_TOKEN peut rester utilisable après un délai, sous réserve de son expiration et de son applicabilité.

Le serveur définit le format et la politique de validation. Il doit pouvoir vérifier l’intégrité du jeton, l’autorité du serveur émetteur, la portée de version QUIC, l’expiration et l’évolution de l’adresse IP source. RFC 9000 ne fixe ni durée universelle, ni taux de réutilisation, ni score de confiance. Une date d’émission peut être inscrite ou permettre de déduire l’expiration. Le client devrait normalement choisir un jeton applicable et inutilisé, sans le réemployer entre différentes tentatives.

La preuve reste bornée. Une même adresse peut desservir plusieurs hôtes derrière un NAT; une adresse peut être réattribuée; un appareil peut changer de réseau. Le jeton peut permettre au serveur de relier la connexion d’émission à une utilisation ultérieure, et sa réutilisation peut renforcer la traçabilité pour des acteurs situés sur le chemin. Le client qui veut rompre cette continuité peut supprimer ses jetons NEW_TOKEN. Ces jetons ne sont pas intégrés à la poignée de main cryptographique : leur validation n’authentifie donc pas le pair.

Elle ne prouve ni continuité de compte, ni identité d’appareil, ni autorisation, ni succès de la requête.

La comparaison d’adresse est essentielle. Si l’adresse a changé, la limite anti-amplification reste obligatoire, même si le jeton influence la décision de ne pas envoyer Retry. Un jeton valide ne supprime donc pas les garde-fous de transport. En cas de jeton invalide, le serveur devrait généralement traiter le client comme non validé et peut envoyer Retry, plutôt que transformer l’invalidité en échec d’identité ou abandonner automatiquement la connexion. L’intégrité doit empêcher devinement, modification et falsification; la relecture doit être empêchée ou limitée.

NEW_TOKEN doit durer plus longtemps que Retry, mais ne devrait pas être accepté plusieurs fois; l’usage unique est encouragé lorsque possible.

DNS sur QUIC illustre utilement cette frontière de confidentialité. Un jeton lié à une adresse peut éviter un aller-retour, mais un changement d’adresse ignoré peut créer de la corrélabilité. La reprise de session peut réduire ce problème sans le supprimer. La bonne pratique consiste à enregistrer une preuve étroite et à ne pas en faire une identité durable.

Le registre doit séparer autorité de l’émetteur et du serveur; type de jeton; dates d’émission et d’expiration; version QUIC; identifiant ou condensat respectueux de la vie privée; concordance d’adresse source; décision de première utilisation ou de réutilisation; résultat de validation; état anti-amplification; décision Retry; authentification de la poignée de main; identité de compte ou d’appareil; autorisation; résultat de la demande; politique de conservation. Les condensats et la conservation limitée sont des recommandations opérationnelles, non des obligations de QUIC.

Cette discipline distingue aussi cinq sujets voisins : l’intégrité de Retry concerne un paquet utilisé immédiatement; la règle des trois fois concerne le plafond d’envoi avant validation; le Connection ID sert au routage; l’acceptation du 0-RTT concerne la relecture des données applicatives; DNS Cookie appartient à un autre protocole. Aucun ne doit être substitué silencieusement à la preuve NEW_TOKEN.