Giacomo Tesio ha scritto:
Il giorno 9 settembre 2018 14:53, Simone Basso <bassosimone@gmail.com> ha scritto:
Prima di introdurre una metrica ("immensa", "piccole", etc.) sarebbe utile capire quale sia la tua definizione di porcata.
Dicesi "porcata" qualunque attività umana che mi vergognerei di spiegare a mia figlia.
Mumble mumble... mi sembra un processo che si basa sulle tue conoscenze e sui tuoi postulati in un dato momento. Secondo me sarebbe meglio un processo in cui si cerca di dare una definizione condivisa e poi si vede se mappa su quelle che consideriamo essere porcate. In ogni caso, non e' assolutamente la parte piu' importante di questa discussione.
(A scanso di equivoci, la riproduzione umana non rientra in questa categoria.)
LOL
Un esempio:
"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. Considero un punto di partenza migliore pensare ai problemi che gli esseri umani vogliono (o hanno voluto) risolvere dato un certo tool, in questo contesto HTTP, dati anche altri vincoli posti dalla societa'. Quindi, per esempio, il fatto che sempre piu' funzionalita' siano state trasportate usando HTTP (penso a cose come il video, la chat, la condivisione di file, etc.) e' anche legato al fatto che spesso (a) usare HTTP era il modo piu' sicuro (inteso come "bullet proof") di far funzionare una applicazione (pensa a tutti i casi in cui certe porte sono bloccate, pensa a come BitTorrent e' stato combattuto a fine anni '00) e (b) in molti contesti - e fino almeno all'avvento del modello app e app store - il browser era il posto migliore dove implementare una applicazione distribuita che funzionasse "quasi ovunque" (modulo Internet Explorer, in alcuni casi, ma comunque c'erano un tot di workaround, come testimoniato dal fatto che sono state implementate applicazioni distribuite molto complesse). Questa evoluzione non era quella che forse era stata prevista all'inizio. Quindi alcune cose sono andate diversamente e alcuni protocolli sono stati adattati ed evoluti di conseguenza. (FTR, nemmeno TCP era pronto per essere TCP, prima di Jacobson, e siamo arrivati - noi umani - solo qualche anno fa scrivere una implementazione del controllo di flusso che non genera code enormi per andare veloce <https://queue.acm.org/detail.cfm?id=3022184>). 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). Per cui ci troviamo oggi con, tra l'altro, un insieme di componenti che non funzionano esattamente nel modo era stato previsto inizialmente. Tra questi, se posso fare un crossover con un altro thread, anche JavaScript che e' passato da essere inizialmente un (tendenzialmente bel) linguaggio toy (ma privo di manico <https://9gag.com/gag/anXEbe0/if-programming-languages-were-weapons>) a uno degli strumenti principe con cui creare applicazioni distribuite (con problemi creati anche da questa evoluzione, alcuni dei quali sono stati citati appunto in altri thread in questa lista). 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. Anche iterando su uno stesso protocollo, sperando di migliorarlo (e non sempre questo avviene, lo dico solo come nota a margine per sottolineare che non ho una visione progressista), puo' succedere che entrino in gioco altri problemi legati alla societa' che rendono complesso passare alla versione migliore. 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. Lo sono per una ventina di persone, figurati se non lo diventano per migliaia di reti che si devono mettere d'accordo e parlarsi. Questo porta a usare un minimo comun denominatore e a implementare sopra a questo soluzioni successive, e quindi in alcuni casi a una stratificazione (di protocolli nel caso che stiamo discutendo, di API se pensiamo che molti OS oggigiorno eseguono come prima applicazione un browser).
"Amore... sono cose da grandi..." "E' complicato?" "No... è idiota!"
Dire che e' idiota mi sembra (crossover con altro thread) un po' Linus-like. Non risolve la questione dal punto di vista razionale. Ci sta solo comunicando che tu hai dei feeling forti nei confronti di questa soluzione. E' una risposta emotiva e, come tale, non credo che vada neanche nella direzione auspicata da una persona con la sindrome di Asperger (per citare uno dei thread in LKML che hai linkato altrove). Il tipo di discussioni a cui mi piace partecipare e' diverso ed e' del tipo "questo cosa secondo me non va bene per ${ragione_razionale}". Le discussioni in cui non mi piace partecipare sono quelle in cui uno dice "questa cosa e' idiota". Mi fanno passare la voglia di discutere.
IMHO è una soluzione - troppo complicata
Rispetto a quali parametri? Ho letto l'RFC draft <https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/?include_text...>. Introduce il tipo MIME "message/dns" che riusa di base i messaggi DNS esistenti. Una frase del draft su cui IMHO riflettere, su questa lista, e' questa "Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but at the cost of opening up implementations to the full set of privacy considerations of HTTP". Non amo i messaggi DNS perche' non sono word aligned, contengono dei salti, e non e' triviale scrivere un decoder sicuro. Ma mi rendo conto delle ragioni per cui probabilmente hanno riutilizzato i messaggi DNS invece di inventare un nuovo formato. In breve (ci torno anche dopo): meno colla da mantenere per utilizzare il sistema che al momento tutti usano (ossia il DNS). Non ho ancora controllato se questa funzionalita' e' anche disponibile via JavaScript e sono molto curioso di vedere se questo e' possibile e che tipo di messaggi siano disponibili in JavaScript. 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, ma mi sembra quantomeno che l'RFC draft faccia un lavoro interessante di enumerazione di vari casi di interazione con le cache, anche se il diavolo sta nell'interazione tra tecnologie complesse (i.e. come dice a un certo punto l'RFC draft "The DoH protocol design allows applications to fully leverage the HTTP ecosystem, including features that are not enumerated here.") Il problema del bootstrap e' probabilmente meno interessante da discutere, almeno qua. Puoi usare un IP hardcodato oppure usare il DNS di sistema per risolvere il nome di dominio che sta nella URL di doh. Usare il DNS di sistema in qualche modo comunque rivela che stai usando uno specifico ISP per fare doh, che comunque e' meglio di rivelare tutte le query (dove "meglio" e' definito rispetto al threat model). (Cmq l'RFC draft e' una lettura molto interessante, che consiglio!)
- 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. Sono 800 righe di codice C. Mi sembra abbastanza semplice da capire, considerando che probabilmente si assume che uno che si interessi di una implementazione DNS conosca il DNS. All'inizio non ero entusiasta dal fatto che avessero riusato il formato del DNS ma IMO ci sta [*]. Da un lato c'e' l'argomento della minimizzazione della colla (almeno a livello di codice C) e dall'altro c'e' che riusare lo stesso formato aiuta a riusare codice e espone chi rivede il codice cercando bug a una palestra simile a quella in cui si era allenato in precedenza (ossia verificare se un certo codice e' una implementazione robusta del parsing DNS). [*] Trasportando su [0..1] la mia scala di entusiasmo per qualcosa, "ci sta" e' 0.56.
- contro intuitiva
Ho speso gia' molti cicli-Simone per rispondere ad altri punti. Qua non riesco a guessare facilmente cosa intendi. Meglio se espandi.
- 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. Un ragionevole punto di partenza iniziale, quindi, specie se si vuole che questa feature funzioni, potrebbe essere "nascondere" questo protocollo dentro qualcosa che tendenzialmente viene fatto passare anche nei casi piu' rough (ho parlato altrove in questo thread di "collateral freedom"). Visto che questo sistema probabilmente dovra' interoperare con il DNS , la cosa che costa meno energie nel backend e' tendenzialmente usare lo stesso formato di messaggi DNS. Ne segue che, anche se l'obiettivo fosse quello di creare un altro protocollo, probabilmente alcune scelte sarebbero simili a doh.
- genera un single point of failure / accentra in oligopoli
Questa e' la direzione che sta prendendo internet, pero'. Non ho a disposizione un controfattuale e non posso giungere a conclusioni razionali, ma comunque mi chiedo se la struttura di internet - almeno in Occidente - sarebbe stata diversa se BitTorrent non fosse stato aggredito cosi' tanto in passato. Ma sono considerazioni romantiche, perche' internet e il mondo vero (cit.) sono strettamente interlacciati, quindi era abbastanza utopico credere (come facevo io) che i rapporti di forza del mondo vero non avrebbero contribuito a modellare internet.
- 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.) Per la cronaca, su macOS, in Nightly doh e' disabilitato e la URL di default e' vuota con hint "https://doh.example.com/dns-query". in Firefox 62 non vedo un setting di alto livello per questa funzionalita', che cmq risulta disabilitata in "about:config". In Firefox 63.0b7 la configurazione e' identica a quella di Firefox Nightly. Stiamo quindi parlando, per il momento, di una feature che e' opt-in.
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.
Come dicevo in precedenza in questo thread, IMO il problema principale sono i casi in cui il DNS viene usato per fare censura e/o sorveglianza. Parlando di censura, questo problema che stiamo discutendo e' solo un capitolo di un piu' grande problema: ossia che la sovranita' digitale di un paese si estende facilmente fino ai resolver DNS degli ISP che operano in quel paese, mentre e' piu' costoso influenzare i servizi che operano al di fuori di tale paese. Per questo, la censura su base DNS e' una delle tecniche piu' diffuse e meno costose. Parlando di sorveglianza, nascondere il proprio traffico agli ISP locali e al governo, e magari rivelarlo a qualche corporation all'estero, puo' essere un compromesso piu' che accettabile per alcuni threat model. (In realta', anche da noi, alcune informazioni possono essere piu' al sicuro se rivelate a una entita' oltre oceano, piu' difficile da raggiungere e magari piu' ostica in tribunale, rispetto a rivelarle al proprio ISP italiano). 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! Simone