Appendice A. Discussione delle modifiche a RFC 4507

L'RFC 4507 [RFC4507] definisce un meccanismo per riprendere una sessione TLS senza mantenere stato lato server, specificando un ticket cifrato che viene mantenuto sul client. Il client presenta questo ticket al server in un'estensione di hello SessionTicket. La codifica nell'RFC 4507 usava la codifica in stile XDR specificata in TLS [RFC4346].

Un errore nella codifica ha fatto sì che la specifica differisse dalle implementazioni distribuite. Al momento della stesura del presente documento non si conoscono implementazioni che seguano la codifica specificata nell'RFC 4507. Questo aggiornamento dell'RFC 4507 allinea il documento a queste implementazioni attualmente distribuite.

La codifica erronea nell'RFC 4507 dava luogo a due campi di lunghezza; uno per il contenuto dell'estensione e uno per il ticket stesso. Quindi, per un ticket lungo 256 byte e che inizia con il valore esadecimale FF FF, la codifica dell'estensione sarebbe la seguente secondo l'RFC 4507:

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

L'aggiornamento proposto nel presente documento riflette ciò che le implementazioni codificano effettivamente, vale a dire rimuove il campo di lunghezza ridondante. Quindi, per un ticket lungo 256 byte e che inizia con il valore esadecimale FF FF, la codifica dell'estensione sarebbe la seguente secondo questo aggiornamento:

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

Un server implementato secondo l'RFC 4507 che riceve un'estensione ticket da un client conforme al presente documento interpreterebbe i primi due byte del ticket come la lunghezza di questo ticket. Ciò comporterà o un campo di lunghezza incoerente o l'elaborazione di un ticket a cui mancano i primi due byte. Nel primo caso, il server dovrebbe rifiutare la richiesta in base a una lunghezza malformata. Nel secondo caso, il server dovrebbe rifiutare il ticket in base a un ticket malformato, a una versione di chiave errata o a una decifratura fallita. Un'implementazione server basata su questo aggiornamento che riceve un'estensione RFC 4507 interpreterebbe il primo campo di lunghezza come lunghezza del ticket e includerebbe i secondi due byte di lunghezza come primi byte del ticket, con il risultato che il ticket viene rifiutato in base a un ticket malformato, a una versione di chiave errata o a una decifratura fallita.

Si noti che la codifica di un'estensione SessionTicket vuota era ambigua nell'RFC 4507. Un'implementazione RFC 4507 potrebbe averla codificata come:

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

oppure potrebbe averla codificata allo stesso modo di questo aggiornamento:

     00 23      Extension type 35
     00 00      Length of extension contents

Un server che desidera supportare i client RFC 4507 dovrebbe rispondere a un'estensione SessionTicket vuota codificata nello stesso modo in cui l'ha ricevuta.

Un'implementazione server può costruire i ticket in modo da poter rilevare un'implementazione RFC 4507, se ne esistesse una, includendo all'inizio dei ticket un cookie che possa essere differenziato da una lunghezza valida. Per esempio, se un'implementazione costruisse i ticket in modo che inizino con i valori esadecimali FF FF, allora potrebbe determinare dove inizia il ticket e determinare correttamente la lunghezza dal tipo di campi di lunghezza presenti.

Il presente documento apporta alcune ulteriori modifiche all'RFC 4507, elencate di seguito.

• Chiarire che il server può consentire la ripresa della sessione usando un ticket senza emettere un nuovo ticket nella Sezione 3.1.

• Chiarire che la durata è relativa al momento in cui il ticket viene ricevuto nella sezione 3.3.

• Chiarire che il messaggio di handshake NewSessionTicket è incluso nell'hash generato per i messaggi Finished nella Sezione 3.3.

• Chiarire l'interazione con il Session ID TLS nella Sezione 3.4.

• Raccomandare l'uso di SHA-256 per la protezione dell'integrità del ticket nella Sezione 4.

• Chiarire che dati aggiuntivi possono essere inclusi nella struttura StatePlaintext nella Sezione 4.