Re: [Hackmeeting] remailer e privacy [ERA: mi fischiavano le…

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?

my 2 cents

c1cc10