11. Sicherheitsüberlegungen
Wenn dieser Mechanismus mit DNS-over-TLS verwendet werden soll, unterliegen diese Nachrichten denselben Einschränkungen wie alle anderen DNS-over-TLS-Nachrichten und DÜRFEN NICHT im Klartext gesendet werden, bevor die TLS-Sitzung aufgebaut ist.
Das Datenfeld des "Encryption Padding" TLV könnte als verdeckter Kanal verwendet werden.
Beim Entwurf neuer DSO-TLVs sollte das Potenzial berücksichtigt werden, dass Daten im TLV als Tracking-Identifikator verwendet werden könnten, und dies sollte vermieden werden, wenn es nicht erforderlich ist.
Bei Verwendung ohne TLS oder ähnlichen kryptografischen Schutz könnte eine böswillige Entität in der Lage sein, eine böswillige unidirektionale DSO-Retry-Delay-Nachricht in den Datenstrom einzuschleusen, die eine unangemessen große RETRY DELAY angibt, was zu einem Denial-of-Service-Angriff gegen den Client führt.
Der Aufbau von DSO-Sitzungen hat Auswirkungen auf die Anzahl der offenen TCP-Verbindungen auf einem DNS-Server. Als Ergebnis können auf dem Server zusätzliche Ressourcen verwendet werden. Da der Server jedoch die Anzahl der aufgebauten DSO-Sitzungen begrenzen kann und auch bestehende DSO-Sitzungen nach Bedarf schließen kann, sollten Denial-of-Service oder Ressourcenerschöpfung kein Problem darstellen.
11.1. Überlegungen zu TLS Zero Round-Trip
DSO ermöglicht den Zero Round-Trip-Betrieb unter Verwendung von TCP Fast Open mit TLS 1.3 [RFC8446] Early Data, um Round-Trips beim Sitzungsaufbau zu reduzieren oder zu eliminieren. TCP Fast Open ist nur in Kombination mit TLS 1.3 Early Data zulässig. Im Rest dieses Abschnitts beziehen wir uns auf TLS 1.3 Early Data in einer TLS Zero Round-Trip Initial Handshake-Nachricht, unabhängig davon, ob sie in einem TCP-SYN-Paket mit Early Data unter Verwendung der TCP Fast Open-Option enthalten ist oder nicht, als "Early Data".
Eine DSO-Nachricht darf als Early Data gesendet werden oder auch nicht. Die Definition für jedes TLV, das als primäres TLV verwendet werden kann, muss angeben, ob dieses TLV als Early Data zulässig ist oder nicht. Nur antwortfordernde Nachrichten sind jemals als Early Data zulässig, und nur Clients dürfen eine DSO-Nachricht als Early Data senden, es sei denn, es liegt eine implizite DSO-Sitzung vor (siehe Abschnitt 5.1).
Für DSO-Nachrichten, die als Early Data zulässig sind, KANN ein Client eine oder mehrere solcher Nachrichten als Early Data einschließen, ohne auf eine DSO-Antwort auf die erste DSO-Anforderungsnachricht warten zu müssen, um den erfolgreichen Aufbau einer DSO-Sitzung zu bestätigen.
Sofern jedoch keine implizite DSO-Sitzung vorliegt, DARF ein Client KEINE unidirektionalen DSO-Nachrichten senden, bis eine DSO-Sitzung gegenseitig aufgebaut wurde.
Ebenso DARF ein Server, sofern keine implizite DSO-Sitzung vorliegt, KEINE DSO-Anforderungsnachrichten senden, bis er eine antwortfordernde DSO-Anforderungsnachricht von einem Client empfangen und eine erfolgreiche NOERROR-Antwort für diese Anforderung übertragen hat.
Es muss darauf geachtet werden, dass als Early Data gesendete DSO-Nachrichten idempotent sind oder anderweitig immun gegen Probleme sind, die aus der unbeabsichtigten Wiedergabe resultieren könnten, die beim Zero Round-Trip-Betrieb auftreten kann.
Es wäre möglich, ein TLV hinzuzufügen, das erfordert, dass der Server erhebliche Arbeit leistet, und dies als Anfangsdaten in einem TCP-SYN-Paket an den Server zu senden. Eine Flut solcher Pakete könnte als DoS-Angriff auf den Server verwendet werden. Keines der hier definierten TLVs hat diese Eigenschaft.
Wenn ein neues TLV spezifiziert wird, das diese Eigenschaft hat, muss dieses TLV als nicht zulässig in Zero Round-Trip-Nachrichten spezifiziert werden. Dies verhindert, dass Arbeit geleistet wird, bis ein Round-Trip vom Server zum Client stattgefunden hat, um zu überprüfen, dass die Quelladresse des Pakets erreichbar ist.
Dokumente, die neue TLVs definieren, müssen angeben, ob jedes neue TLV als Early Data gesendet werden darf. Solche Dokumente müssen eine Bedrohungsanalyse im Abschnitt Sicherheitsüberlegungen für jedes im Dokument definierte TLV enthalten, das als Early Data gesendet werden darf. Diese Bedrohungsanalyse sollte basierend auf den Ratschlägen in den Abschnitten 2.3, 8 und Anhang E.5 der TLS 1.3-Spezifikation [RFC8446] durchgeführt werden.