Il progetto Rustls ha pubblicato la release 0.23.44 con un cambiamento che da solo merita attenzione: i certificati ML-DSA sono ora abilitati per impostazione predefinita. Non si tratta di una semplice aggiunta di ciphersuite, ma dello spostamento di una tecnicia post-quantum dal piano delle opzioni a quello del comportamento standard. Per chi gestisce endpoint TLS self-hosted davanti a server di inference LLM, il significato va oltre la notizia di manutenzione: cambia la pressione sui componenti che stanno a monte e a valle della libreria.

ML-DSA è uno schema di firma pensato per autenticare in scenari in cui un computer quantistico maturo potrebbe compromettere le firme tradizionali. In un deployment locale, il certificato serve a dimostrare che il gateway che espone un modello self-hosted è davvero chi dice di essere. La parte di scambio chiavi, invece, resta un problema separato; quindi l'abilitazione dei certificati ML-DSA non rende automaticamente confidenziale l'intero canale. Va letta come un tassello di un percorso composito, non come una soluzione completa.

Il passaggio a default ha un effetto di secondo ordine poco discusso: riduce il costo decisionale per i team piccoli. Prima, abilitare certificati post-quantum richiedeva una scelta esplicita e una verifica di compatibilità. Ora chi aggiorna Rustls si trova l'impostazione già attiva e deve semmai decidere se disattivarla. Questo inverte l'onere della prova: il comportamento prudente non è più aggiungere, ma rimuovere. Per i team che gestiscono API di inference self-hosted su reti aziendali o air-gapped, dove il controllo dei certificati è spesso manuale, l'aggiornamento può far emergere incompatibilità con tooling di emissione CA private, HSM o client più datati.

Il vantaggio più immediato va agli ambienti regolati che devono dimostrare una strategia di migrazione post-quantum anche per i servizi interni: una libreria che attiva ML-DSA di default offre documentazione implicita del percorso. Il costo aggiuntivo ricade invece sui manutentori di stack legacy che avevano congelato toolchain e automazioni di provisioning dei certificati. Per loro l'aggiornamento non è trasparente: può trasformarsi in una corsa a verificare formati, firme e supporto nei propri sistemi.

C'è poi un segnale strutturale: la crittografia post-quantum sta entrando nella fase in cui le librerie scelgono per l'utente. Non è più un flag per pionieri, ma una proprietà di default. Questo può accelerare l'adozione, ma aumenta anche il rischio di falsa sicurezza: un certificato ML-DSA protegge l'autenticazione, non garantisce che ogni parte del canale sia resistente. Per chi valuta deployment on-premise, esistono trade-off da considerare tra aggiornare subito le dipendenze TLS e verificare l'intera catena di emissione e di client supportati. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off. Il prossimo indicatore da osservare non sarà solo quanti adottano Rustls, ma quanti strumenti di PKI interna sono pronti a emettere e revocare certificati ML-DSA senza introdurre attrito operativo. Se quel ritardo persiste, il default diventerà un problema di compatibilità prima che un vantaggio di sicurezza.