Anhang A. Diskussion der Änderungen an RFC 4507

RFC 4507 [RFC4507] definiert einen Mechanismus zur Wiederaufnahme einer TLS-Sitzung ohne Aufrechterhaltung von serverseitigem Zustand, indem ein verschlüsseltes Ticket spezifiziert wird, das auf dem Client gehalten wird. Der Client legt dieses Ticket dem Server in einer SessionTicket-Hello-Erweiterung vor. Die Kodierung in RFC 4507 verwendete die in TLS [RFC4346] spezifizierte XDR-artige Kodierung.

Ein Fehler in der Kodierung führte dazu, dass die Spezifikation von den eingesetzten Implementierungen abwich. Zum Zeitpunkt dieses Schreibens sind keine Implementierungen bekannt, die der in RFC 4507 angegebenen Kodierung folgen. Diese Aktualisierung von RFC 4507 bringt das Dokument mit diesen derzeit eingesetzten Implementierungen in Übereinstimmung.

Eine fehlerhafte Kodierung in RFC 4507 führte zu zwei Längenfeldern; eines für den Inhalt der Erweiterung und eines für das Ticket selbst. Für ein Ticket, das 256 Byte lang ist und mit dem Hex-Wert FF FF beginnt, wäre die Kodierung der Erweiterung gemäß RFC 4507 daher wie folgt:

     00 23          Ticket Extension type 35
     01 02          Length of extension contents
     01 00          Length of ticket
     FF FF .. ..    Actual ticket

Die in diesem Dokument vorgeschlagene Aktualisierung spiegelt wider, was Implementierungen tatsächlich kodieren, nämlich sie entfernt das redundante Längenfeld. Für ein Ticket, das 256 Byte lang ist und mit dem Hex-Wert FF FF beginnt, wäre die Kodierung der Erweiterung gemäß dieser Aktualisierung daher wie folgt:

     00 23          Extension type 35
     01 00          Length of extension contents (ticket)
     FF FF .. ..    Actual ticket

Ein gemäß RFC 4507 implementierter Server, der eine Ticket-Erweiterung von einem Client empfängt, der diesem Dokument entspricht, würde die ersten zwei Bytes des Tickets als die Länge dieses Tickets interpretieren. Dies führt entweder zu einem inkonsistenten Längenfeld oder zur Verarbeitung eines Tickets, dem die ersten zwei Bytes fehlen. Im ersten Fall sollte der Server die Anforderung aufgrund einer fehlerhaften Länge zurückweisen. Im zweiten Fall sollte der Server das Ticket aufgrund eines fehlerhaften Tickets, einer falschen Schlüsselversion oder einer fehlgeschlagenen Entschlüsselung zurückweisen. Eine auf dieser Aktualisierung basierende Server-Implementierung, die eine RFC 4507-Erweiterung empfängt, würde das erste Längenfeld als die

Länge des Tickets interpretieren und die zweiten zwei Längenbytes als die ersten Bytes des Tickets aufnehmen, was dazu führt, dass das Ticket aufgrund eines fehlerhaften Tickets, einer falschen Schlüsselversion oder einer fehlgeschlagenen Entschlüsselung zurückgewiesen wird.

Beachten Sie, dass die Kodierung einer leeren SessionTicket-Erweiterung in RFC 4507 mehrdeutig war. Eine RFC 4507-Implementierung hat sie möglicherweise wie folgt kodiert:

     00 23      Extension type 35
     00 02      Length of extension contents
     00 00      Length of ticket

oder sie hat sie möglicherweise genauso kodiert wie diese Aktualisierung:

     00 23      Extension type 35
     00 00      Length of extension contents

Ein Server, der RFC 4507-Clients unterstützen möchte, sollte auf eine leere SessionTicket-Erweiterung antworten, die genauso kodiert ist, wie er sie empfangen hat.

Eine Server-Implementierung kann Tickets so konstruieren, dass sie eine RFC 4507-Implementierung, falls es eine gäbe, erkennen kann, indem sie ein Cookie am Anfang der Tickets aufnimmt, das von einer gültigen Länge unterschieden werden kann. Wenn eine Implementierung beispielsweise Tickets so konstruierte, dass sie mit den Hex-Werten FF FF beginnen, dann könnte sie bestimmen, wo das Ticket beginnt, und die Länge korrekt aus der Art der vorhandenen Längenfelder bestimmen.

Dieses Dokument nimmt einige zusätzliche Änderungen an RFC 4507 vor, die unten aufgeführt sind.

• Klarstellung, dass der Server die Sitzungswiederaufnahme unter Verwendung eines Tickets zulassen kann, ohne ein neues Ticket auszustellen, in Abschnitt 3.1.

• Klarstellung, dass die Lebensdauer relativ zum Zeitpunkt des Empfangs des Tickets ist, in Abschnitt 3.3.

• Klarstellung, dass die NewSessionTicket-Handshake-Nachricht in den für die Finished-Nachrichten erzeugten Hash aufgenommen wird, in Abschnitt 3.3.

• Klarstellung der Interaktion mit der TLS Session ID in Abschnitt 3.4.

• Empfehlung der Verwendung von SHA-256 für den Integritätsschutz des Tickets in Abschnitt 4.

• Klarstellung, dass zusätzliche Daten in die Struktur StatePlaintext aufgenommen werden können, in Abschnitt 4.