4.2. Sequence Number and Epoch (Numero di sequenza ed epoca)

DTLS utilizza un numero di sequenza esplicito o parzialmente esplicito, anziché implicito, trasportato nel campo sequence_number del record. I numeri di sequenza sono mantenuti separatamente per ogni epoca, con ogni sequence_number inizialmente pari a 0 per ogni epoca.

Il numero di epoca è inizialmente zero ed è incrementato ogni volta che il materiale di chiave cambia e un mittente mira a richiavare. Ulteriori dettagli sono forniti nella sezione 6.1.

4.2.1. Processing Guidelines (Linee guida di elaborazione)

Poiché i record DTLS potrebbero essere riordinati, un record dall'epoca M può essere ricevuto dopo che l'epoca N (dove N > M) è iniziata. Le implementazioni DOVREBBERO scartare i record delle epoche precedenti ma POSSONO scegliere di conservare il materiale di chiave delle epoche precedenti fino al MSL predefinito specificato per TCP [RFC0793] per consentire il riordinamento dei pacchetti. (Si noti che l'intenzione qui è che gli implementatori utilizzino le linee guida attuali dell'IETF per il MSL, come specificato in [RFC0793] o successori, non che tentino di interrogare il MSL che lo stack TCP del sistema sta utilizzando.)

Al contrario, è possibile che i record protetti con la nuova epoca vengano ricevuti prima del completamento di una stretta di mano. Ad esempio, il server può inviare il suo messaggio Finished e quindi iniziare a trasmettere dati. Le implementazioni POSSONO bufferizzare o scartare tali record, sebbene quando DTLS viene utilizzato su trasporti affidabili (ad esempio, SCTP [RFC4960]), DOVREBBERO essere bufferizzati ed elaborati una volta completata la stretta di mano. Si noti che le restrizioni di TLS su quando i record possono essere inviati si applicano ancora e il ricevitore tratta i record come se fossero stati inviati nell'ordine corretto.

Le implementazioni DEVONO inviare ritrasmissioni di messaggi persi utilizzando la stessa epoca e materiale di chiave della trasmissione originale.

Le implementazioni DEVONO abbandonare un'associazione o richiavare prima di consentire al numero di sequenza di avvolgersi.

Le implementazioni NON DEVONO consentire all'epoca di avvolgersi, ma DEVONO invece stabilire una nuova associazione, terminando la vecchia associazione.

4.2.2. Reconstructing the Sequence Number and Epoch (Ricostruzione del numero di sequenza e dell'epoca)

Quando si ricevono record DTLS protetti, il destinatario non ha un valore completo di epoca o numero di sequenza nel record e quindi c'è qualche possibilità di ambiguità. Poiché il numero di sequenza completo viene utilizzato per calcolare il nonce per record e l'epoca determina le chiavi, il fallimento nella ricostruzione di questi valori porta al fallimento nella deprotezione del record, e quindi le implementazioni POSSONO utilizzare un meccanismo di loro scelta per determinare i valori completi. Questa sezione fornisce un algoritmo che è comparativamente semplice e che le implementazioni sono RACCOMANDATE a seguire.

Se i bit dell'epoca corrispondono a quelli dell'epoca corrente, allora le implementazioni DOVREBBERO ricostruire il numero di sequenza calcolando il numero di sequenza completo che è numericamente più vicino a uno più il numero di sequenza del record più alto deprotetto con successo nell'epoca corrente.

Durante la fase di stretta di mano, i bit dell'epoca indicano inequivocabilmente la chiave corretta da utilizzare. Dopo il completamento della stretta di mano, se i bit dell'epoca non corrispondono a quelli dell'epoca corrente, le implementazioni DOVREBBERO utilizzare l'epoca passata più recente che ha bit corrispondenti, e quindi ricostruire il numero di sequenza per quell'epoca come descritto sopra.

4.2.3. Record Number Encryption (Crittografia del numero di record)

In DTLS 1.3, quando i record vengono cifrati, anche i numeri di sequenza dei record vengono cifrati. Il modello di base è che l'algoritmo di cifratura sottostante utilizzato con l'algoritmo AEAD viene utilizzato per generare una maschera che viene poi XORata con il numero di sequenza.

Quando l'AEAD è basato su AES, allora la maschera viene generata calcolando AES-ECB sui primi 16 byte del testo cifrato:

Mask = AES-ECB(sn_key, Ciphertext[0..15])

Quando l'AEAD è basato su ChaCha20, allora la maschera viene generata trattando i primi 4 byte del testo cifrato come contatore di blocco e i successivi 12 byte come nonce, passandoli alla funzione di blocco ChaCha20 (Sezione 2.3 di [CHACHA]):

Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])

Il sn_key è calcolato come segue:

[sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)

[sender] denota il lato mittente. Il valore Secret per epoca da utilizzare è descritto nella sezione 7.3 di [TLS13]. Si noti che viene utilizzata una nuova chiave per ogni epoca: poiché l'epoca viene inviata in chiaro, ciò non comporta ambiguità.

Il numero di sequenza cifrato viene calcolato XORando i byte iniziali della maschera con la rappresentazione su cavo del numero di sequenza. La decifratura viene realizzata attraverso lo stesso processo.

Questa procedura richiede che la lunghezza del testo cifrato sia di almeno 16 byte. I ricevitori DEVONO rifiutare i record più corti come se avessero fallito la deprotezione, come descritto nella sezione 4.5.2. I mittenti DEVONO riempire i testi in chiaro corti (utilizzando il meccanismo di riempimento del record convenzionale) per creare un testo cifrato di lunghezza adeguata. Si noti che la maggior parte degli algoritmi AEAD DTLS ha un tag di autenticazione di 16 byte e non necessita di riempimento. Tuttavia, alcuni algoritmi, come TLS_AES_128_CCM_8_SHA256, hanno un tag di autenticazione più corto e potrebbero richiedere riempimento per input corti.

Le suite di cifratura future, che non sono basate su AES o ChaCha20, DEVONO definire la propria crittografia del numero di sequenza del record per essere utilizzate con DTLS.

Si noti che la crittografia del numero di sequenza viene applicata solo alla struttura DTLSCiphertext e non alla struttura DTLSPlaintext, anche se contiene anche un numero di sequenza.