11. Considérations de Sécurité
Si ce mécanisme doit être utilisé avec DNS-over-TLS, alors ces messages sont soumis aux mêmes contraintes que tout autre message DNS-over-TLS et NE DOIVENT PAS être envoyés en clair avant que la session TLS ne soit établie.
Le champ de données du TLV "Encryption Padding" (Remplissage de chiffrement) pourrait être utilisé comme un canal caché.
Lors de la conception de nouveaux TLV DSO, le potentiel pour que les données dans le TLV soient utilisées comme identifiant de suivi doit être pris en considération et doit être évité lorsqu'il n'est pas requis.
Lorsqu'il est utilisé sans TLS ou une protection cryptographique similaire, une entité malveillante peut être en mesure d'injecter un message unidirectionnel DSO Retry Delay malveillant dans le flux de données, spécifiant un RETRY DELAY déraisonnablement grand, provoquant une attaque par déni de service contre le client.
L'établissement de sessions DSO a un impact sur le nombre de connexions TCP ouvertes sur un serveur DNS. Des ressources supplémentaires peuvent être utilisées sur le serveur en conséquence. Cependant, parce que le serveur peut limiter le nombre de sessions DSO établies et peut également fermer les sessions DSO existantes selon les besoins, le déni de service ou l'épuisement des ressources ne devrait pas être une préoccupation.
11.1. Considérations sur le Zéro Aller-Retour TLS
DSO permet une opération zéro aller-retour utilisant TCP Fast Open avec des données précoces (early data) TLS 1.3 [RFC8446] pour réduire ou éliminer les allers-retours dans l'établissement de session. TCP Fast Open n'est autorisé qu'en combinaison avec les données précoces TLS 1.3. Dans le reste de cette section, nous faisons référence aux données précoces TLS 1.3 dans un message de poignée de main initiale TLS zéro aller-retour, qu'il soit inclus ou non dans un paquet TCP SYN avec des données précoces utilisant l'option TCP Fast Open, comme "données précoces".
Un message DSO peut ou non être autorisé à être envoyé en tant que données précoces. La définition de chaque TLV pouvant être utilisé comme TLV Primaire est tenue d'indiquer si ce TLV est autorisé ou non en tant que données précoces. Seuls les messages nécessitant une réponse sont autorisés en tant que données précoces, et seuls les clients sont autorisés à envoyer un message DSO en tant que données précoces, sauf s'il existe une session DSO implicite (voir Section 5.1).
Pour les messages DSO qui sont autorisés en tant que données précoces, un client PEUT inclure un ou plusieurs de ces messages en tant que données précoces sans avoir à attendre une réponse DSO au premier message de demande DSO pour confirmer l'établissement réussi d'une session DSO.
Cependant, sauf s'il existe une session DSO implicite, un client NE DOIT PAS envoyer de messages unidirectionnels DSO avant qu'une session DSO n'ait été mutuellement établie.
De même, sauf s'il existe une session DSO implicite, un serveur NE DOIT PAS envoyer de messages de demande DSO avant d'avoir reçu un message de demande DSO nécessitant une réponse d'un client et d'avoir transmis une réponse NOERROR réussie pour cette demande.
Il faut veiller à ce que les messages DSO envoyés en tant que données précoces soient idempotents ou soient autrement immunisés contre tout problème qui pourrait résulter de la relecture involontaire qui peut se produire avec l'opération zéro aller-retour.
Il serait possible d'ajouter un TLV qui nécessite que le serveur effectue un travail important et de l'envoyer au serveur en tant que données initiales dans un paquet TCP SYN. Une inondation de tels paquets pourrait être utilisée comme une attaque DoS sur le serveur. Aucun des TLV définis ici n'a cette propriété.
Si un nouveau TLV est spécifié qui a cette propriété, ce TLV doit être spécifié comme non autorisé dans les messages zéro aller-retour. Cela empêche le travail d'être effectué jusqu'à ce qu'un aller-retour se soit produit du serveur vers le client pour vérifier que l'adresse source du paquet est accessible.
Les documents qui définissent de nouveaux TLV doivent indiquer si chaque nouveau TLV peut être envoyé en tant que données précoces. De tels documents doivent inclure une analyse des menaces dans la section des considérations de sécurité pour chaque TLV défini dans le document qui peut être envoyé en tant que données précoces. Cette analyse des menaces doit être effectuée sur la base des conseils donnés dans les Sections 2.3, 8 et l'Annexe E.5 de la spécification TLS 1.3 [RFC8446].