sans Perfect-Forward-Secrecy, ça expose toutes les connexions à un décryptage a-posteriori sur une échelle de temps plutôt courte.
Il ne faut pas tout mélanger. Les clefs de DNSSEC ne sont pas utilisées pour chiffrer, elles ne font que signer.
Si quelqu’un casse la clef DNSSEC d’un domaine (ou même de la racine) dans cinq ans, ça lui permettra, à ce moment-là, de falsifier des signatures DNSSEC (et donc, dans le cas de DANE, de falsifier un enregistrement TLSA et de faire accepter un certificat qui n’est pas celui publié par le propriétaire du site visé).
Ça ne permettra absolument pas de revenir déchiffrer les communications préalablement enregistrées avant que la clef ne soit cassée, il n’y a même pas besoin de Forward Secrecy pour le garantir.
[^] # Re: DANE
Posté par gouttegd . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 9. Dernière modification le 04 mai 2015 à 11:38.
Il ne faut pas tout mélanger. Les clefs de DNSSEC ne sont pas utilisées pour chiffrer, elles ne font que signer.
Si quelqu’un casse la clef DNSSEC d’un domaine (ou même de la racine) dans cinq ans, ça lui permettra, à ce moment-là, de falsifier des signatures DNSSEC (et donc, dans le cas de DANE, de falsifier un enregistrement TLSA et de faire accepter un certificat qui n’est pas celui publié par le propriétaire du site visé).
Ça ne permettra absolument pas de revenir déchiffrer les communications préalablement enregistrées avant que la clef ne soit cassée, il n’y a même pas besoin de Forward Secrecy pour le garantir.