1. Introduction (Introduzione)

L'obiettivo principale di TLS è fornire un canale sicuro (Secure Channel) tra due peer comunicanti; l'unico requisito del trasporto sottostante è un flusso di dati affidabile e ordinato. In particolare, il canale sicuro dovrebbe fornire le seguenti proprietà:

• Authentication (Autenticazione): Il lato server del canale è sempre autenticato; il lato client è autenticato opzionalmente. L'autenticazione può avvenire tramite crittografia asimmetrica (Asymmetric Cryptography) (ad esempio, RSA [RSA], l'Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], o l'Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) o una chiave pre-condivisa simmetrica (PSK).

• Confidentiality (Riservatezza): I dati inviati sul canale dopo la sua creazione sono visibili solo agli endpoint. TLS non nasconde la lunghezza dei dati che trasmette, ma gli endpoint possono riempire i record TLS per oscurare le lunghezze e migliorare la protezione contro le tecniche di analisi del traffico.

• Integrity (Integrità): I dati inviati sul canale dopo la sua creazione non possono essere modificati dagli attaccanti senza essere rilevati.

Queste proprietà dovrebbero valere anche di fronte a un attaccante che ha il controllo completo della rete, come descritto in [RFC3552]. Vedere l'Appendice E per una dichiarazione più completa delle proprietà di sicurezza rilevanti.

TLS consiste di due componenti principali:

• Un protocollo di handshake (Handshake Protocol) (Sezione 4) che autentica le parti comunicanti, negozia modalità e parametri crittografici, e stabilisce il materiale di chiave condiviso. Il protocollo di handshake è progettato per resistere alle manomissioni; un attaccante attivo non dovrebbe essere in grado di forzare i peer a negoziare parametri diversi da quelli che utilizzerebbero se la connessione non fosse sotto attacco.

• Un protocollo dei record (Record Protocol) (Sezione 5) che utilizza i parametri stabiliti dal protocollo di handshake per proteggere il traffico tra i peer comunicanti. Il protocollo dei record divide il traffico in una serie di record, ciascuno dei quali è protetto indipendentemente utilizzando le chiavi di traffico.

TLS è indipendente dal protocollo applicativo; i protocolli di livello superiore possono essere stratificati in modo trasparente su TLS. Tuttavia, lo standard TLS non specifica come i protocolli aggiungano sicurezza con TLS; come avviare l'handshake TLS e come interpretare i certificati di autenticazione scambiati sono lasciati al giudizio dei progettisti e implementatori dei protocolli che funzionano su TLS.

Questo documento definisce TLS versione 1.3. Sebbene TLS 1.3 non sia direttamente compatibile con le versioni precedenti, tutte le versioni di TLS incorporano un meccanismo di versionamento che consente a client e server di negoziare in modo interoperabile una versione comune se supportata da entrambi i peer.

Questo documento sostituisce e rende obsolete le versioni precedenti di TLS, inclusa la versione 1.2 [RFC5246]. Rende anche obsoleto il meccanismo dei ticket TLS definito in [RFC5077] e lo sostituisce con il meccanismo definito nella Sezione 2.2. Poiché TLS 1.3 cambia il modo in cui le chiavi sono derivate, aggiorna [RFC5705] come descritto nella Sezione 7.5. Cambia anche il modo in cui i messaggi del protocollo Online Certificate Status Protocol (OCSP) sono trasportati e quindi aggiorna [RFC6066] e rende obsoleto [RFC6961] come descritto nella Sezione 4.4.2.1.

1.1 Conventions and Terminology (Convenzioni e terminologia)

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono tutte in maiuscolo, come mostrato qui.

Vengono utilizzati i seguenti termini:

client: L'endpoint che inizia la connessione TLS.

connection (connessione): Una connessione a livello di trasporto tra due endpoint.

endpoint: Il client o il server della connessione.

handshake: Una negoziazione iniziale tra client e server che stabilisce i parametri delle loro interazioni successive all'interno di TLS.

peer: Un endpoint. Quando si discute di un particolare endpoint, "peer" si riferisce all'endpoint che non è il soggetto della discussione.

receiver (ricevitore): Un endpoint che sta ricevendo record.

sender (mittente): Un endpoint che sta trasmettendo record.

server: L'endpoint che non ha avviato la connessione TLS.

1.2 Major Differences from TLS 1.2 (Differenze principali da TLS 1.2)

Di seguito è riportato un elenco delle principali differenze funzionali tra TLS 1.2 e TLS 1.3. Non è esaustivo e ci sono molte differenze minori.

• L'elenco degli algoritmi di cifratura simmetrica supportati è stato ripulito da tutti gli algoritmi considerati legacy. Quelli rimanenti sono tutti algoritmi Authenticated Encryption with Associated Data (AEAD). Il concetto di Cipher Suite è stato modificato per separare i meccanismi di autenticazione e scambio chiavi dall'algoritmo di protezione dei record (inclusa la lunghezza della chiave segreta) e da un hash da utilizzare sia con la funzione di derivazione delle chiavi che con il Message Authentication Code (MAC) dell'handshake.

• È stata aggiunta una modalità Zero Round-Trip Time (0-RTT), che risparmia un viaggio di andata e ritorno durante la configurazione della connessione per alcuni dati applicativi, al costo di alcune proprietà di sicurezza.

• Sono state rimosse le cipher suite RSA statiche e Diffie-Hellman; tutti i meccanismi di scambio chiavi basati su chiave pubblica ora forniscono Forward Secrecy (segretezza in avanti).

• Tutti i messaggi di handshake dopo il ServerHello sono ora crittografati. Il messaggio EncryptedExtensions appena introdotto consente a varie estensioni precedentemente inviate in chiaro nel ServerHello di godere anche della protezione della riservatezza.

• Le funzioni di derivazione delle chiavi sono state riprogettate. Il nuovo design consente un'analisi più semplice da parte dei crittografi grazie alle loro migliorate proprietà di separazione delle chiavi. La funzione HMAC-based Extract-and-Expand Key Derivation Function (HKDF) viene utilizzata come primitiva sottostante.

• La macchina a stati dell'handshake è stata significativamente ristrutturata per essere più coerente e rimuovere messaggi superflui come ChangeCipherSpec (tranne quando necessario per la compatibilità con i middlebox).

• Gli algoritmi a curva ellittica sono ora nella specifica di base e sono inclusi nuovi algoritmi di firma, come EdDSA. TLS 1.3 ha rimosso la negoziazione del formato del punto a favore di un singolo formato di punto per ciascuna curva.

• Sono stati apportati altri miglioramenti crittografici, tra cui la modifica del padding RSA per utilizzare il RSA Probabilistic Signature Scheme (RSASSA-PSS) e la rimozione della compressione, del Digital Signature Algorithm (DSA) e dei gruppi Ephemeral Diffie-Hellman (DHE) personalizzati.

• Il meccanismo di negoziazione della versione TLS 1.2 è stato deprecato a favore di un elenco di versioni in un'estensione. Ciò aumenta la compatibilità con i server esistenti che hanno implementato in modo errato la negoziazione della versione.

• La ripresa della sessione con e senza stato lato server, così come le cipher suite basate su PSK delle versioni TLS precedenti, sono state sostituite da un singolo nuovo scambio PSK.

• I riferimenti sono stati aggiornati per puntare alle versioni aggiornate degli RFC (ad esempio, RFC 5280 anziché RFC 3280).

1.3 Updates Affecting TLS 1.2 (Aggiornamenti che riguardano TLS 1.2)

Questo documento definisce diverse modifiche che influenzano opzionalmente le implementazioni di TLS 1.2, incluse quelle che non supportano anche TLS 1.3:

• Un meccanismo di protezione contro il downgrade della versione è descritto nella Sezione 4.1.3.

• Gli schemi di firma RSASSA-PSS sono definiti nella Sezione 4.2.3.

• L'estensione ClientHello "supported_versions" può essere utilizzata per negoziare la versione di TLS da utilizzare, in preferenza al campo legacy_version del ClientHello.

• L'estensione "signature_algorithms_cert" consente a un client di indicare quali algoritmi di firma può validare nei certificati X.509.

Inoltre, questo documento chiarisce alcuni requisiti di conformità per le versioni precedenti di TLS; vedere la Sezione 9.3.

---