On Fri, Aug 30, 2013 at 02:42:27PM +0200, c1cc10 wrote:
> Vediamo se riesco a riassumere e rilanciare.
>
> Il problema posto da Naif ? relativo al modello di sicurezza. In
> sostanza lui dice: se affido la mia mail a un server che ? diventato un
> aggregatore di
> comunicazioni "contro il sistema", allora sono pi? a rischio di
> intercettazione perch? il succitato sistema avr? un punto certo di
> attacco su cui fare
> leva.
>
> A/I (via Bomboclat) propone degli strumenti per impedire le
> intercettazioni lato server (no logs, tls).
>
> Pasky dice: con ECN noi non tracciamo nulla e i dischi sono crittati.
> Pertanto non l'intercettazione non ? un problema perch? non ci sono dati
> su cui lavorare.
>
> Naif (preventivamente) risponde: la possibilit? di stabilire
> correlazioni temporali tra ricezione e spedizione delle mail, aggiunta
> alla possibilit? di accedere
> a informazioni su IP che correlano indirizzi digitali a quelli reali,
> considerando anche che ? possibile intercettare l'altro capo della
> comunicazione mail, confuta le argomentazioni soprastanti.
>
> A questo punto Calamari e Putro (in una certa forma) spostano il
> problema dal design di rete allo strumento. Ovvero dicono: se ognuno di
> noi usasse PGP (quindi lato client), sia la
> sicurezza a livello di trasporto che quella a livello applicativo
> sarebbe fatta salva perch? si tratta di una crittazione end-to-end.
> Tralascio volontariamente le considerazioni etiche, politiche e
> culturali perch? rientrano solo marginalmente nella discussione tecnica,
> comportando analisi del comportamento e non di design
> della comunicazione (mail).
>
> Bona. Se quanto sopra ? corretto (e spero che lo sia :) il mio
> contributo ? il seguente: perch? non ragioniamo a livello protocollare?
> POP3, IMAP ed SMTP di fatto sono rimasti sempre gli stessi da 30 anni a
> questa parte. La crittazione intrinseca della comunicazione non esiste.
> Si pu? aggiungere un layer TLS per garantire l'identit? del proprio
> server SMTP con i certificati e proteggere il trasporto delle
> informazioni dal mittente al proprio STMP server, ma una volta che il
> messaggio ha raggiunto quest'ultimo il livello di sicurezza SCOMPARE,
> nel senso che ? a discrezione del gestore del servizio. Non solo, anche
> se questi fosse (come per A/I, ECN, etc etc) un trusted partner, il
> mittente non avr? nessuna garanzia sul secondo SMTP server (quello che
> delivera la mail al destinatario) n? sul canale di comunicazione che
> intercorre tra i due server.
>
> Ecco, secondo me dato quanto detto prima la logica di Naif ha senso.
> Anche le comunicazioni via webmail (gmail et similia) sono affette dal
> medesimo design flow.
> E purtroppo questo non si risolve con il PGP perch? questa soluzione
> sposta la responsabilit? dal mezzo di comunicazione ai singoli capi
> della catena di comunicazione. Ne consegue che
> se io dovessi decidere che PGP mi risolve il problema, allora dovrei
> implementarlo su tutti i miei dispositivi (fissi e mobili) e
> preoccuparmi che vengano implementati nelle comunicazioni via web
> (ergo webmail). Non so se qlkno riesce o trova delle mediazioni
> applicabili, ma a me sembra infattibile.
>
> Invece un protocollo che critti di default il contenuto della mail,
> anche lasciando in chiaro gli header, mi sembrerebbe gi? un IMMENSO
> passo in avanti. E' chiaro che nessuno dei big players
> l? fuori ha interesse a ratificare e implementare una soluzione
> protocollare di questo tipo, ma funzionerebbe? Potrebbe discendere da un
> lavoro sul protocollo una famiglia di clients e server
> in grado di abbattere la difficolt? d'uso degli strumenti di crittazione
> attuali?
>
> E ne varrebbe la pena, anche solo per vedere cosa succede se cominciamo
> a dare alternative valide e utilizzabili al mondo, un po' come si faceva
> quando spingevamo per installare GNU/Linux?
>
Lascerei fuori dalla tua analisi la questione dell' "attenzione" rivolta
in misura maggiore o minore a certi soggetti anziche' altri, perche' in
questi tempi di fiber tapping globale mi sembra sostanzialmente irrilevante;
il resto ribadisce ancora una volta la differenza tra sistemi end-to-end
e sistemi che non lo sono -- sorpresa, i primi sono preferibili! Qualsiasi
sistema che abbia questa caratteristica pero' dovra' evidentemente essere
"implementato su tutti i tuoi dispositivi" (e' la definizione di "end"),
indipendentemente dal protocollo....
Inoltre, per quanto riguarda lo sviluppo di nuovi protocolli temo che si sottovaluti
il problema dell'interoperabilita' -- ci sono un certo numero di proposte
attualmente in giro per una "email migliore" (pond, cables, etc.) ed hanno
tutte in comune il grosso ostacolo rappresentato dall'adozione di un nuovo
paradigma comunicativo (ovvero non li usa nessuno).
Una proposta forse migliore e' quella che si sta tentando di finalizzare su
https://leap.se/ e che rimane compatibile con l'infrastruttura email esistente
(spostando il problema sulla key discovery, ovvero la parte piu' "rognosa"
di PGP).
--
ale
