IETF 103 discuterà le bozze su privacy DNS, TLS e IPv6

All'IETF 103 di Bangkok, le sessioni dei gruppi di lavoro iniziano lunedì con un fitto programma di quattro giorni, e l'Internet Society's Internet Technology Team ha pubblicato un'anteprima dei temi che contano per la privacy del DNS, la crittografia del trasporto e la prossima generazione di indirizzamento internet. L'IETF, o Internet Engineering Task Force, è l'organismo di standard aperti in cui gli ingegneri concordano le regole tecniche che fanno funzionare internet. Poiché questa volta sono stati assegnati solo quattro giorni, l'agenda di lunedì copre diversi gruppi contemporaneamente, e gli organizzatori notano che chi non può partecipare di persona può comunque partecipare da remoto.

Lunedì mattina inizia con il gruppo di lavoro IPv6 Operations, noto come v6ops, alle 09.00 ora locale (UTC+7). Dall'ultimo incontro, il gruppo ha pubblicato quattro RFC, tra cui Happy Eyeballs v2, che aiuta i dispositivi a scegliere più agevolmente tra connessioni IPv6 e IPv4. La sessione si aprirà con una presentazione su CERNET2, una rete di ricerca e istruzione solo IPv6 in Cina. Sul tavolo ci sono poi quattro bozze, tre delle quali nuove. Una, intitolata IPv6-Ready DNS/DNSSEC Infrastructure, raccomanda come distribuire DNS64, una tecnica che consente ai dispositivi solo IPv6 di raggiungere servizi solo IPv4 sintetizzando indirizzi IPv6, perché in alcune circostanze questa modifica dei record DNS può rompere DNSSEC, il livello di sicurezza che firma i dati DNS. Un'altra bozza, IPv6 Address Assignment to End-Sites, sostituisce RFC 6177 e prende la migliore pratica operativa corrente da RIPE-690, ribadendo che la politica di assegnazione e le linee guida appartengono alla comunità dei registri internet regionali. Una terza bozza, Pros and Cons of IPv6 Transition Technologies for IPv4aaS, confronta diversi scenari di casi d'uso per le cinque tecnologie di transizione IPv4 come servizio più importanti. La quarta, NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks, è una bozza aggiornata che copre applicazioni o dispositivi che usano indirizzi IPv4 letterali, API non conformi a IPv6 o host solo IPv4 su una rete solo IPv6.

Allo stesso tempo, il gruppo di lavoro Routing Over Low power and Lossy networks, o roll, discuterà un aggiornamento al progetto ROLL-BIER che estende RPL, il protocollo di routing per reti a bassa potenza e con perdite, per supportare Bit Index Explicit Replication (BIER) in ambienti con aggiornamenti limitati e con perdite. Sono in programma anche altre sette bozze tutte relative ai miglioramenti di RPL. Più tardi nella mattinata alle 11.20 ora locale, il Crypto Forum (cfrg) tiene la sua sessione. Il gruppo non ha ancora pubblicato un'agenda, ma le sue bozze attualmente attive coprono lo scambio di chiavi pubbliche, la transizione dalla crittografia classica a quella post-quantistica, miglioramenti della casualità per i protocolli di sicurezza, meccanismi di re-keying per chiavi simmetriche e firme basate su hash.

Dopo pranzo, due sessioni si svolgono in parallelo alle 13.50. Il gruppo di lavoro Transport Layer Security (TLS) ha la prima delle sue due sessioni, con la seconda mercoledì pomeriggio. Tra le bozze importanti ci sono la specifica proposta DTLS 1.3 e Connection Identifiers for DTLS, un meccanismo progettato per evitare la necessità di handshaking aggiuntivo quando l'indirizzo di rete di un dispositivo cambia a causa del rebinding NAT. Il gruppo prenderà in considerazione anche una proposta per deprecare TLS 1.0 e 1.1 perché quelle versioni più vecchie mancano del supporto per le suite di cifratura attuali e raccomandate. Altre bozze riguardano l'autenticazione TLS tramite certificati ETSI TS 103 097 e IEEE 1609.2, un'estensione TLS 1.3 che consente a un server di autenticarsi con un certificato fornendo anche una chiave pre-condivisa (PSK) come input, e PSK universali per TLS che usano un passaggio di derivazione della chiave aggiuntivo in modo che lo stesso segreto possa essere riutilizzato per tutti gli hash della funzione di derivazione della chiave TLS 1.3. È stato proposto anche uno statuto rivisto del gruppo di lavoro. Allo stesso tempo, il gruppo di lavoro Domain Name System Operations (dnsop) ha due bozze di particolare interesse: una delinea come eseguire un'istanza del server radice sulla stessa macchina di un resolver ricorsivo per ridurre il tempo necessario per ottenere una risposta, e un'altra specifica un modo per i resolver di indicare ai client quali server DNS over HTTPS (DoH) sono associati a loro. DoH è il metodo di invio delle query DNS tramite connessioni web crittografate, e questo meccanismo di scoperta renderebbe più facile per i dispositivi trovare automaticamente l'endpoint crittografato di un resolver.

La sessione finale della giornata appartiene al gruppo di lavoro IPv6 over Networks of Resource-constrained Nodes, o 6lo, alle 16.10. Le bozze all'ordine del giorno includono un aggiornamento a RFC 6775 per supportare estensioni di registrazione che semplificano le operazioni nei router 6LoWPAN, una tecnologia che consente a piccoli dispositivi alimentati a batteria di usare IPv6 su reti wireless a bassa potenza. Un'altra bozza aggiorna Address Protected Neighbor Discovery for Low-power and Lossy Networks. Una terza aggiorna RFC 4944 con un semplice protocollo per recuperare frammenti di pacchetti su una rete mesh, e il gruppo preparerà la bozza IPv6 Backbone Router per una Working Group Last Call. La sessione si conclude con un rapporto sulle prestazioni sull'inoltro e il recupero dei frammenti.

Nel complesso, l'agenda di lunedì mostra come l'IETF stia lavorando sull'impianto invisibile che decide se una query DNS è privata, se una connessione usa la crittografia moderna e se le reti possono continuare a funzionare mentre gli indirizzi IPv4 si esauriscono. La discussione del DNSOP sulla scoperta di DoH è particolarmente rilevante per gli utenti comuni, perché se i resolver possono pubblicizzare automaticamente i loro endpoint crittografati, più persone otterranno la privacy del DNS senza dover configurare manualmente le impostazioni tecniche. Deprecare TLS 1.0 e 1.1 spinge il web lontano dalla vecchia crittografia debole, mentre il lavoro sulla transizione a IPv6 aiuta gli operatori a pianificare reti che non dipendono più dallo spazio IPv4 scarso. Per i lettori che vogliono ridurre ciò che il proprio resolver può vedere o modificare, l'uso di un servizio DNS privato e crittografato come AEU DNS consente di inviare le query tramite HTTPS o TLS e di esaminare personalmente le politiche sulla privacy pubblicate dal servizio. Gli standard sono ancora in discussione a Bangkok, ma la direzione è chiara: più crittografia, più IPv6 e più orientamento operativo per un internet più sicuro.