7.1. "alpn" et "no-default-alpn"

Les SvcParamKeys "alpn" et "no-default-alpn" indiquent ensemble l'ensemble des identifiants de protocole de négociation de protocole de couche application (ALPN) et des protocoles de transport associés pris en charge par ce point de terminaison de service (l'"ensemble ALPN SVCB").

Comme avec Alt-Svc, chaque identifiant de protocole ALPN est utilisé pour identifier le protocole d'application et la suite de protocoles associée prise en charge par le point de terminaison (la "suite de protocoles"). La présence d'un identifiant de protocole ALPN dans l'ensemble ALPN SVCB indique que ce point de terminaison de service, décrit par TargetName et les autres paramètres (par exemple, "port"), offre un service avec la suite de protocoles associée à cet identifiant ALPN.

Les clients filtrent l'ensemble des identifiants ALPN pour correspondre aux suites de protocoles qu'ils prennent en charge, et cela informe le protocole de transport sous-jacent utilisé (tel que QUIC sur UDP ou TLS sur TCP). Les identifiants de protocole ALPN qui n'identifient pas de manière unique une suite de protocoles (par exemple, une séquence d'identification qui peut être utilisée avec TLS et DTLS) ne sont pas compatibles avec cette SvcParamKey et ne doivent pas être inclus dans l'ensemble ALPN SVCB.

7.1.1. Représentation

Les ALPN sont identifiés par leur "séquence d'identification" enregistrée (alpn-id), qui est une séquence de 1 à 255 octets.

alpn-id = 1*255OCTET

Pour "alpn", la valeur de présentation doit être une liste séparée par des virgules d'un ou plusieurs alpn-id. Les implémentations de fichiers de zone peuvent interdire les caractères "," et "\" dans les ID ALPN au lieu d'implémenter la procédure d'échappement de liste de valeurs, en s'appuyant sur le format de clé opaque (par exemple, key1=\002h2) dans le cas où ces caractères sont nécessaires.

La valeur de format de transmission pour "alpn" se compose d'au moins un alpn-id préfixé par sa longueur sous forme d'un seul octet, et ces paires longueur-valeur sont concaténées pour former la SvcParamValue. Ces paires doivent exactement remplir la SvcParamValue ; sinon, la SvcParamValue est mal formée.

Pour "no-default-alpn", les valeurs de présentation et de format de transmission doivent être vides. Lorsque "no-default-alpn" est spécifié dans un RR, "alpn" doit également être spécifié pour que le RR soit "auto-cohérent" (Section 2.4.3).

Chaque schéma utilisant cette SvcParamKey définit un "ensemble par défaut" d'ID ALPN pris en charge par presque tous les clients et serveurs ; cet ensemble peut être vide. Pour déterminer l'ensemble ALPN SVCB, le client commence par la liste des alpn-id de la SvcParamKey "alpn", et il ajoute l'ensemble par défaut sauf si la SvcParamKey "no-default-alpn" est présente.

7.1.2. Utilisation

Pour établir une connexion au point de terminaison, les clients doivent :

1. Soit SVCB-ALPN-Intersection l'ensemble des protocoles dans l'ensemble ALPN SVCB que le client prend en charge.

2. Soit Intersection-Transports l'ensemble des transports (par exemple, TLS, DTLS, QUIC) impliqués par les protocoles dans SVCB-ALPN-Intersection.

3. Pour chaque transport dans Intersection-Transports, construire une ProtocolNameList contenant les séquences d'identification de tous les protocoles ALPN pris en charge par le client pour ce transport, sans tenir compte de l'ensemble ALPN SVCB.

Par exemple, si l'ensemble ALPN SVCB est ["http/1.1", "h3"] et que le client prend en charge HTTP/1.1, HTTP/2 et HTTP/3, le client pourrait tenter de se connecter en utilisant TLS sur TCP avec une ProtocolNameList de ["http/1.1", "h2"] et pourrait également tenter une connexion en utilisant QUIC avec une ProtocolNameList de ["h3"].

Une fois que le client a construit un ClientHello, la négociation du protocole dans cette poignée de main se déroule comme spécifié dans [ALPN], sans tenir compte de l'ensemble ALPN SVCB.

Les clients peuvent implémenter une procédure de secours, en utilisant un transport moins préféré si les transports plus préférés ne parviennent pas à se connecter. Ce comportement de secours est vulnérable à la manipulation par un attaquant réseau qui bloque les transports plus préférés, mais il peut être nécessaire pour la compatibilité avec les réseaux existants.

Avec cette procédure en place, un attaquant qui peut modifier le DNS et le trafic réseau peut empêcher une connexion de transport réussie mais ne peut pas autrement interférer avec la sélection du protocole ALPN. Cette procédure garantit également que chaque ProtocolNameList inclut au moins un protocole de l'ensemble ALPN SVCB.

Les clients ne doivent pas tenter de se connecter à un point de terminaison de service dont l'ensemble ALPN SVCB ne contient aucun protocole pris en charge.

Pour garantir la cohérence du comportement, les clients peuvent rejeter l'ensemble SVCB RRset et revenir à l'établissement de connexion de base si tous les RR compatibles indiquent "no-default-alpn", même si la connexion aurait pu réussir en utilisant un protocole ALPN non par défaut.

Les opérateurs de zone doivent s'assurer qu'au moins un RR dans chaque RRset prend en charge les transports par défaut. Cela permet la compatibilité avec le plus grand nombre de clients.