Quella "carta" è piuttosto terra-terra; non specifica che "TLS dovrebbe fornire riservatezza e integrità" perché ciò è considerato ovvio; invece, la carta è una roadmap per il futuro TLS 1.3 e quindi documenta le modifiche desiderabili da TLS 1.2.
Per quanto riguarda i messaggi della mailing list che stai indicando, penso che tu li stia interpretando in modo eccessivo. Il tipo di "scatole middleware" può essere, ad esempio, un sistema di bilanciamento del carico che deve ispezionare ClientHello messaggi in modo che reindirizzi i tentativi di ripresa della sessione al server che ha gestito quest'ultima sessione. Oppure un server RADIUS utilizzando EAP-TLS come protocollo di autenticazione: in EAP-TLS, il layer EAP deve riconoscere i limiti del record per poterli includere nei messaggi EAP. Queste sono ragioni molto legittime e non malvagie per i sistemi che risiedono tra il client TLS e il server per ispezionare i pacchetti e capire effettivamente le parti non crittografate del protocollo.
Il dialogo nella mailing-list è principalmente il seguente:
-
Dobbiamo crittografare tutte le cose! La nostra carta richiede ! Cambiamo il formato dell'intestazione del record.
-
Ciò interromperà i sistemi che si basano sul formato del record; questo potrebbe compromettere la compatibilità con le scatole del middleware (che alluderemo solo nei termini più vaghi). È veramente richiesto? O è un Cambio Gratuito, che è esplicitamente proibito dalla Nostra Carta?
-
Questo è necessario perché il campo del tipo di contenuto nell'intestazione consente malevoli attacchi di analisi del traffico (che non descriverò perché in realtà non conosco un simile attacco). L'analisi del traffico è molto seria! Cripta tutte le cose!
-
Ma la nostra Carta non parla di analisi del traffico! E l'analisi del traffico è molto più difficile da sconfiggere rispetto alla semplice crittografia delle intestazioni del tipo di contenuto del record. L'analisi del traffico è fuori dall'ambito!
e così via, ad nauseam. Intervallati nello scambio sono veri e propri bit di informazione, dai quali possiamo concludere che i membri del WG non sembrano aver raggiunto (ancora) un consenso sul livello di compatibilità a ritroso che TLS 1.3 dovrebbe avere con le versioni precedenti del protocollo. Soprattutto dal momento che tale compatibilità è definita in relazione al sistema esistente, distribuito che interagisce con il formato on-the-wire in vari modi che non sono necessariamente ben documentati.
Tuttavia, leggere queste e-mail come se il WG stesse cercando di promuovere una spionaggio generalizzato simile alla NSA sarebbe errato. Questo è un caso classico di "ragionamento del comitato" quando gli obiettivi e i vincoli reali sono stati specificati in modo insufficiente. Si può prevedere che la definizione di TLS 1.3 richiederà un po 'di tempo (anni) per giungere a buon fine.