Zum Hauptinhalt springen

1. Einleitung

Das Transport Layer Security (TLS) Protocol Version 1.2 ist in [RFC5246] spezifiziert. Diese Spezifikation umfasst das Framework für Erweiterungen von TLS, Überlegungen beim Entwerfen solcher Erweiterungen (siehe Abschnitt 7.4.1.4 von [RFC5246]) und IANA-Überlegungen zur Zuweisung neuer Erweiterungs-Codepunkte; sie spezifiziert jedoch keine bestimmten Erweiterungen außer Signaturalgorithmen (siehe Abschnitt 7.4.1.4.1 von [RFC5246]).

Dieses Dokument bietet die Spezifikationen für bestehende TLS-Erweiterungen. Es ist größtenteils die Anpassung und Bearbeitung von Material aus RFC 4366, das TLS-Erweiterungen für TLS 1.0 (RFC 2246) und TLS 1.1 (RFC 4346) abdeckte.

1.1. Behandelte spezifische Erweiterungen​

Die hier beschriebenen Erweiterungen konzentrieren sich auf die Erweiterung der durch die TLS-Protokollnachrichtenformate bereitgestellten Funktionalität. Andere Themen, wie das Hinzufügen neuer Cipher-Suites, werden zurückgestellt.

Die in diesem Dokument definierten Erweiterungstypen sind:

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), trusted_ca_keys(3),
    truncated_hmac(4), status_request(5), (65535)
} ExtensionType;

Insbesondere ermöglichen die in diesem Dokument beschriebenen Erweiterungen:

  • TLS-Clients können dem TLS-Server den Namen des Servers mitteilen, den sie kontaktieren. Diese Funktionalität ist wünschenswert, um sichere Verbindungen zu Servern zu erleichtern, die mehrere 'virtuelle' Server unter einer einzigen zugrunde liegenden Netzwerkadresse hosten.

  • TLS-Clients und -Server können die maximale zu sendende Fragmentlänge aushandeln. Diese Funktionalität ist wünschenswert aufgrund von Speicherbeschränkungen bei einigen Clients und Bandbreitenbeschränkungen bei einigen Zugangsnetzwerken.

  • TLS-Clients und -Server können die Verwendung von Client-Zertifikat-URLs aushandeln. Diese Funktionalität ist wünschenswert, um Speicher auf eingeschränkten Clients zu sparen.

  • TLS-Clients können TLS-Servern anzeigen, welche CA-Wurzelschlüssel (Certification Authority) sie besitzen. Diese Funktionalität ist wünschenswert, um mehrere Handshake-Fehler zu verhindern, die TLS-Clients betreffen, die aufgrund von Speicherbeschränkungen nur eine kleine Anzahl von CA-Wurzelschlüsseln speichern können.

  • TLS-Clients und -Server können die Verwendung von gekürzten Message Authentication Codes (MACs) aushandeln. Diese Funktionalität ist wünschenswert, um Bandbreite in eingeschränkten Zugangsnetzwerken zu sparen.

  • TLS-Clients und -Server können aushandeln, dass der Server dem Client während eines TLS-Handshakes Zertifikatsstatusinformationen (z. B. eine OCSP-Antwort (Online Certificate Status Protocol) [RFC2560]) sendet. Diese Funktionalität ist wünschenswert, um das Senden einer Certificate Revocation List (CRL) über ein eingeschränktes Zugangsnetzwerk zu vermeiden und somit Bandbreite zu sparen.

TLS-Clients und -Server können die in diesem Dokument beschriebenen Erweiterungen verwenden. Die Erweiterungen sind so konzipiert, dass sie abwärtskompatibel sind, was bedeutet, dass TLS-Clients, die die Erweiterungen unterstützen, mit TLS-Servern kommunizieren können, die sie nicht unterstützen, und umgekehrt.

Beachten Sie, dass alle mit diesen Erweiterungen verbundenen Nachrichten, die während des TLS-Handshakes gesendet werden, in die Hash-Berechnungen einbezogen werden MÜSSEN, die an "Finished"-Nachrichten beteiligt sind.

Beachten Sie auch, dass alle in diesem Dokument definierten Erweiterungen nur relevant sind, wenn eine Sitzung initiiert wird. Ein Client, der die Wiederaufnahme einer Sitzung anfordert, weiß im Allgemeinen nicht, ob der Server diese Anforderung akzeptieren wird, und daher SOLLTE er dieselben Erweiterungen senden, die er senden würde, wenn er keine Wiederaufnahme versuchen würde. Wenn ein Client einen oder mehrere der definierten Erweiterungstypen in einem erweiterten Client-Hello einschließt, während er die Sitzungswiederaufnahme anfordert:

  • Die Server-Namensanzeigeerweiterung KANN vom Server verwendet werden, wenn er entscheidet, ob eine Sitzung wiederaufgenommen werden soll oder nicht, wie in Abschnitt 3 beschrieben.

  • Wenn die Wiederaufnahmeanforderung abgelehnt wird, wird die Verwendung der Erweiterungen wie normal ausgehandelt.

  • Wenn andererseits die ältere Sitzung wiederaufgenommen wird, MUSS der Server die Erweiterungen ignorieren und ein Server-Hello senden, das keine der Erweiterungstypen enthält. In diesem Fall wird die Funktionalität dieser Erweiterungen, die während der ursprünglichen Sitzungsinitiierung ausgehandelt wurde, auf die wiederaufgenommene Sitzung angewendet.

1.2. In diesem Dokument verwendete Konventionen​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

Letztes Update am