Anhang A. Diskussion der Änderungen an RFC 4507

RFC 4507 [RFC4507] definiert einen Mechanismus zur Wiederaufnahme einer TLS-Sitzung ohne Aufrechterhaltung des serverseitigen Zustands durch Spezifizierung eines verschlüsselten Tickets, das auf dem Client gehalten wird. Der Client präsentiert dieses Ticket dem Server in einer SessionTicket Hello-Erweiterung. Die Kodierung in RFC 4507 verwendete die XDR-Style-Kodierung, die in TLS [RFC4346] spezifiziert ist.

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

Die fehlerhafte Kodierung in RFC 4507 führte zu zwei Längenfeldern; eines für den Erweiterungsinhalt und eines für das Ticket selbst. Daher würde für ein Ticket, das 256 Bytes lang ist und mit dem Hex-Wert FF FF beginnt, die Kodierung der Erweiterung gemäß RFC 4507 wie folgt aussehen:

00 23          Ticket Extension type 35
01 02          Länge des Erweiterungsinhalts
01 00          Länge des Tickets
FF FF .. ..    Tatsächliches Ticket

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

00 23          Extension type 35
01 00          Länge des Erweiterungsinhalts (Ticket)
FF FF .. ..    Tatsächliches Ticket

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 ohne Ausstellung eines neuen Tickets zulassen kann (Abschnitt 3.1).
• Klarstellung, dass die Lebensdauer relativ zu dem Zeitpunkt ist, zu dem das Ticket empfangen wird (Abschnitt 3.3).
• Empfehlung zur Verwendung von SHA-256 für den Integritätsschutz des Tickets (Abschnitt 4).