Anzitutto grazie per la risposta chiara e precisa. Mi scuso anzitutto per l'ironia se in qualche modo ti ha offeso: visto che obbiettavi alla assenza di definizione per "porcata" ti ho fornito quella che uso nella vita quotidiana. E riportando un dialogo (immaginario, ma assolutamente verosimile) con la mia figlia maggiore, definivo sinteticamente "idiota" una scelta tecnologica che (per le ragioni elencate successivamente) non ritengo efficiente, efficace, sicura o... razionale. Non intendevo (e non credevo di) offendere nessuno ed in realtà non ho alcun sentimento forte nei confronti del DoH (contrariamente a JavaScript, per esempio). Il resto della tua mail è assolutamente interessante, ma temo che siamo in disaccordo su alcuni assunzioni di base. Il giorno 20 settembre 2018 15:24, Simone Basso <bassosimone@gmail.com> ha scritto:
Giacomo Tesio ha scritto:
"Papà, perché avete deciso di incapsulare un protocollo binario (il DNS) dentro un protocollo binario crittografato (HTTP2 su SSL) progettato per trasferire ipertesti attraverso connessioni persistenti?"
Stai usando come punto di partenza la tecnologia: HTTP2 e' un protocollo progettato per trasferire ipertesti attraverso connessioni persistenti quindi usarlo per trasferire il DNS e' incosistente con la mission originale del protocollo (aka "una porcata").
Sono in disaccordo con questo punto di vista, che mi sembra molto rigido. [...] La mia tesi e' che questo tipo di evoluzione sia abbastanza tipica di molti contesti umani (in alcuni casi seguiamo il percorso di minima resistenza e in altri reinventiamo la ruota, per divertimento, per profitto, per mancata conoscenza, o per ottime ragioni).
Io direi invece che fossilizzarsi su una singola porta e veicolare tutto attraverso un singolo protocollo, sia piuttosto rigido. Ora, trattandosi di SOFTware, non abbiamo la scusa che modificare l'infrastruttura dopo l'installazione della stessa è impossibile. E' sempre possibile. Può essere costoso, ma è possibile. Il punto dunque diventa: 1. se i problemi dell'infrastruttura sono così gravi da giustificare l'investimento 2. se i costi generati dai workaround a tali problemi (ovvero nuovi problemi) siano maggiori dei costi dell'intervento. Secondo me, entrambe le condizioni suddette sono vere da tempo. E' ora dunque che smettiamo di buttare pezze su pezze, ci fermiamo un attimo a ragionare e troviamo soluzioni migliori. Questo nell'obbiettivo, che suggerisci e che condivido, di servire l'umanità.
Che le cose siano cresciute in un modo non previsto e' un problema che sicuramente va affrontato, ma e' anche difficile immaginarsi tutto in modo perfetto all'inizio e non avere cambiamenti successivi.
Naturalmente. Purtroppo questo spiega i problemi, ma non giustifica il mancato intervento per risolverli seriamente.
Un caso che mi viene in mente e' IPv6. Passare tutti a IPv6 quando siamo in cosi' tanti a essere connessi e' complicato, perche' richiede di mettere d'accordo un tot di persone, di coordinarsi. E i problemi di coordinamento sono sempre difficili da risolvere.
Anche per questo dico che la Tecnologia è Politica. Le "difficoltà" di IPv6 sono una prova di questo fatto. Coordinarsi è facile al livello giusto. Per assurdo: basta una legge che dice che le comunicazioni Internet via IPv4 sono vietate dal giorno tot. Coordinamento effettuato.
IMHO è una soluzione - troppo complicata
Rispetto a quali parametri?
Rispetto ad un protocollo ad hoc, che è possibile.
Un aspetto su cui sicuramente riflettere, parzialmente anticipato dalla frase che ho citato sopra, e' l'interazione tra doh e le cache HTTP. Non sono un esperto di cache [...]
La questione non è se riescono a considerare tutti i casi (e non riescono, vedi gli standard con cui Mozilla giustifica il suo rifiuto di proteggere i propri utenti dagli attacchi che ho descritto), ma che quel intero albero di possibilità (foresta?) non dovrebbe trovarsi su questa strada. Keep It Simple.
- parziale (solo su un browser! e anche fossero tutti i browser, solo sui browser!)
Esiste una implementazione per libcurl che sto leggendo mentre ti rispondo.
Perché ping dovrebbe dipendere da libcurl? Ti rendi conto? Non è questione di quante righe di codice (molte di più di 800 se includi le dipendenze), è che non ha senso!
- contro intuitiva
Ho speso gia' molti cicli-Simone per rispondere ad altri punti. Qua non riesco a guessare facilmente cosa intendi. Meglio se espandi.
Metti un protocollo binario dentro un'altro progettato per una cosa totalmente diversa, ti pare intuitivo?
- sub ottimale: perché non progettare un protocollo migliore del DNS, invece?
Implementare un sistema nuovo di questo tipo che rimpiazzi il DNS su scala mondiale e' un task massivo.
Allora è meglio iniziare subito! ;-)
- genera un single point of failure / accentra in oligopoli
Questa e' la direzione che sta prendendo internet, pero'.
E speriamo di riuscire a virare in tempo! Non aumenterei ulteriormente l'accentramento, se posso evitarlo. Anzi dovremmo lavorare per ridurlo!
- non mi fido di CloudFlare (che ha anche accesso ad altri dati personali, in quanto CDN)
Se ti fidi dei ToS, come ho scritto in questo thread, puoi constatare che sono dei ToS abbastanza buoni. Se non ti fidi dei ToS, puoi vedere se c'e' un servizio alternativo oppure puoi deciderti di fidarti di piu' del tuo ISP. (Alla fine, di qualcuno ti devi fidare per quasi tutte le applicazioni piu' complesse di `ping 127.0.0.1`, ed e' giusto che sia tu a decidere di chi fidarti e di chi non fidarti.)
Non mi fido del ToS di Cloudflare e mi fido di più del mio ISP.
Se l'obbiettivo è proteggere gli utenti da MitM DNS da parte di ISP come Vodafone, la soluzione non è tecnica, ma politica: bisogna semplicemente vietare il MitM DNS.
Riguardo al vietare il MitM DNS, Quintarelli aveva scritto "non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria?" e "credo sia la direttiva 2002/58/EC, ma i giuristi possono essere piu' precisi...".
Quindi ci serve una mano da un giurista per capire meglio!
Sottoscrivo. Assolutamente.
Simone
Giacomo