5. Extension Negotiation (Negoziazione dell'estensione)

5.1. Extension Definition (Definizione dell'estensione)

Questo documento definisce una nuova estensione TLS, extended_master_secret (con tipo di estensione 0x0017), che viene utilizzata per segnalare sia al client che al server di utilizzare il calcolo del segreto principale esteso. Il campo extension_data di questa estensione è vuoto. Pertanto, l'intera codifica dell'estensione è 00 17 00 00 (in esadecimale).

Sebbene questo documento faccia riferimento solo a TLS, l'estensione proposta qui può essere utilizzata anche con Datagram TLS (DTLS) [RFC6347].

Se il client e il server concordano su questa estensione e ha luogo un handshake completo, sia il client che il server DEVONO utilizzare l'algoritmo di derivazione del segreto principale esteso, come definito nella Section 4. Tutti gli altri calcoli crittografici rimangono invariati.

5.2. Client and Server Behavior: Full Handshake (Comportamento del client e del server: Handshake completo)

Di seguito, utilizziamo la frase "interrompere l'handshake" come abbreviazione per terminare l'handshake inviando un avviso fatale handshake_failure.

In tutti gli handshake, un client che implementa questo documento DEVE inviare l'estensione extended_master_secret nel suo ClientHello.

Se un server che implementa questo documento riceve l'estensione extended_master_secret, DEVE includere l'estensione nel suo messaggio ServerHello.

Se sia il ClientHello che il ServerHello contengono l'estensione, la nuova sessione utilizza il calcolo del segreto principale esteso.

Se il server riceve un ClientHello senza l'estensione, DOVREBBE interrompere l'handshake se non desidera interoperare con client legacy. Se sceglie di continuare l'handshake, allora NON DEVE includere l'estensione nel ServerHello.

Se un client riceve un ServerHello senza l'estensione, DOVREBBE interrompere l'handshake se non desidera interoperare con server legacy.

Se il client e il server scelgono di continuare un handshake completo senza l'estensione, DEVONO utilizzare la derivazione standard del segreto principale per la nuova sessione. In questo caso, la nuova sessione non è protetta dai meccanismi descritti in questo documento. Quindi, gli implementatori dovrebbero seguire le linee guida nella Section 5.4 per evitare scenari di utilizzo pericolosi. In particolare, il segreto principale derivato dalla nuova sessione non dovrebbe essere utilizzato per l'autenticazione a livello di applicazione.

5.3. Client and Server Behavior: Abbreviated Handshake (Comportamento del client e del server: Handshake abbreviato)

Il client NON DOVREBBE offrire un handshake abbreviato per riprendere una sessione che non utilizza un segreto principale esteso. Invece, DOVREBBE offrire un handshake completo.

Se il client sceglie di offrire un handshake abbreviato anche per tali sessioni al fine di supportare la ripresa insicura legacy, allora la connessione corrente non è protetta dai meccanismi in questo documento. Quindi, il client dovrebbe seguire le linee guida nella Section 5.4 per evitare scenari di utilizzo pericolosi. In particolare, la rinegoziazione non è più sicura su questa connessione, anche se il client e il server supportano l'estensione dell'indicazione di rinegoziazione [RFC5746].

Quando offre un handshake abbreviato, il client DEVE inviare l'estensione extended_master_secret nel suo ClientHello.

Se un server riceve un ClientHello per un handshake abbreviato che offre di riprendere una sessione precedente nota, si comporta come segue:

Se la sessione originale non utilizzava l'estensione extended_master_secret ma il nuovo ClientHello contiene l'estensione, allora il server NON DEVE eseguire l'handshake abbreviato. Invece, DOVREBBE continuare con un handshake completo (come descritto nella Section 5.2) per negoziare una nuova sessione.
Se la sessione originale utilizzava l'estensione extended_master_secret ma il nuovo ClientHello non la contiene, il server DEVE interrompere l'handshake abbreviato.
Se né la sessione originale né il nuovo ClientHello utilizzano l'estensione, il server DOVREBBE interrompere l'handshake. Se continua con un handshake abbreviato per supportare la ripresa insicura legacy, la connessione non è più protetta dai meccanismi in questo documento e il server dovrebbe seguire le linee guida nella Section 5.4.
Se il nuovo ClientHello contiene l'estensione e il server sceglie di continuare l'handshake, allora il server DEVE includere l'estensione extended_master_secret nel suo messaggio ServerHello.

Se un client riceve un ServerHello che accetta un handshake abbreviato, si comporta come segue:

Se la sessione originale non utilizzava l'estensione extended_master_secret ma il nuovo ServerHello contiene l'estensione, il client DEVE interrompere l'handshake.
Se la sessione originale utilizzava l'estensione ma il nuovo ServerHello non contiene l'estensione, il client DEVE interrompere l'handshake.

Se il client e il server continuano l'handshake abbreviato, derivano le chiavi di connessione per la nuova sessione come di consueto dal segreto principale della sessione originale.

5.4. Interoperability Considerations (Considerazioni sull'interoperabilità)

Per consentire l'interoperabilità con client e server legacy, un peer TLS può decidere di accettare handshake completi che utilizzano il calcolo del segreto principale legacy. In tal caso, devono differenziare tra sessioni che utilizzano segreti principali legacy ed estesi aggiungendo un flag allo stato della sessione.

Se un client o un server sceglie di continuare con un handshake completo senza l'estensione del segreto principale esteso, allora la nuova sessione diventa vulnerabile all'attacco di sincronizzazione della chiave man-in-the-middle descritto nella Section 1. Quindi, il client o il server NON DEVE esportare alcun materiale chiave basato sul nuovo segreto principale per alcuna successiva autenticazione a livello di applicazione. In particolare, DEVE disabilitare [RFC5705] e qualsiasi Extensible Authentication Protocol (EAP) che si basa sull'autenticazione composta [COMPOUND-AUTH].

Se un client o un server sceglie di continuare un handshake abbreviato per riprendere una sessione che non utilizza il segreto principale esteso, allora la connessione corrente diventa vulnerabile a un attacco di sincronizzazione del registro di handshake man-in-the-middle come descritto nella Section 1. Quindi, il client o il server NON DEVE utilizzare i verify_data dell'handshake corrente per l'autenticazione a livello di applicazione. In particolare, il client DEVE disabilitare la rinegoziazione e qualsiasi utilizzo del channel binding "tls-unique" [RFC5929] sulla connessione corrente.

Se la sessione originale utilizza un segreto principale esteso ma il ClientHello o il ServerHello nell'handshake abbreviato non include l'estensione, PUÒ essere sicuro continuare l'handshake abbreviato poiché è protetto dal segreto principale esteso della sessione originale. Questo scenario può verificarsi, ad esempio, quando un server che implementa questa estensione stabilisce una sessione ma la sessione viene successivamente ripresa su un server diverso che non supporta l'estensione. Poiché tali situazioni sono insolite e probabilmente il risultato di configurazioni errate transitorie o involontarie, questo documento raccomanda che il client e il server DEVONO interrompere tali handshake.