2. Conventions and Terminology (Konventionen und Terminologie)
2. Conventions and Terminology (Konventionen und Terminologie)
Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "NOT RECOMMENDED" (NICHT EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
Die folgenden Begriffe werden verwendet:
client (Client): Der Endpunkt, der die DTLS-Verbindung initiiert.
association (Assoziation): Gemeinsamer Zustand zwischen zwei Endpunkten, der durch einen DTLS-Handshake eingerichtet wurde.
connection (Verbindung): Synonym für Assoziation.
endpoint (Endpunkt): Entweder der Client oder der Server der Verbindung.
epoch (Epoche): Ein Satz kryptografischer Schlüssel, die für Verschlüsselung und Entschlüsselung verwendet werden.
handshake (Handshake): Eine anfängliche Verhandlung zwischen Client und Server, die die Parameter der Verbindung festlegt.
peer (Peer): Ein Endpunkt. Bei der Diskussion eines bestimmten Endpunkts bezieht sich "peer" auf den Endpunkt, der vom Hauptdiskussionsgegenstand entfernt ist.
receiver (Empfänger): Ein Endpunkt, der Datensätze empfängt.
sender (Sender): Ein Endpunkt, der Datensätze überträgt.
server (Server): Der Endpunkt, der die DTLS-Verbindung nicht initiiert hat.
CID: Connection ID (Verbindungs-ID).
MSL: Maximum Segment Lifetime (Maximale Segmentlebensdauer).
Es wird angenommen, dass der Leser mit [TLS13] vertraut ist. Wie in TLS 1.3 hat das HelloRetryRequest dasselbe Format wie eine ServerHello-Nachricht, aber der Einfachheit halber verwenden wir den Begriff HelloRetryRequest in diesem Dokument, als ob es sich um eine separate Nachricht handeln würde.
DTLS 1.3 verwendet das Netzwerk-Byte-Order (Big-Endian) Format zur Codierung von Nachrichten basierend auf dem in [TLS13] und früheren (D)TLS-Spezifikationen definierten Codierungsformat.
Es wird auch angenommen, dass der Leser mit [RFC9146] vertraut ist, da dieses Dokument die CID-Funktionalität auf DTLS 1.3 anwendet.
Die Abbildungen in diesem Dokument veranschaulichen verschiedene Kombinationen von DTLS-Protokollaustauschen, und die Symbole haben die folgende Bedeutung:
'+' zeigt bemerkenswerte Erweiterungen an, die in der zuvor genannten Nachricht gesendet wurden.
'*' zeigt optionale oder situationsabhängige Nachrichten/Erweiterungen an, die nicht immer gesendet werden.
'{}' zeigt Nachrichten an, die mit Schlüsseln geschützt sind, die von einem [sender]_handshake_traffic_secret abgeleitet wurden.
'[]' zeigt Nachrichten an, die mit Schlüsseln geschützt sind, die von traffic_secret_N abgeleitet wurden.