Envoyer (削除) la (削除ここまで) une clé à utiliser dans la réponse est une mauvaise idée.
Si la clé n'est pas fournie pas un moyen de confiance par le destinataire, rien n'empêche l'attaquant de substituer une autre clé et faire un MITM.
C'est comme envoyer des données à un serveur TLS qui n'aurait pas de CA.
Rien ne prouve que c'est bien le certificat du serveur demandé.
La seule "validation" implicite c'est via le réseau de confiance et les signatures de clé, mais là encore, rien ne prouve que la clé récupérée est la bonne et pas une clé révoquée.
En plus:
- ça bloate les headers en grossissant la clé avec toutes les signatures.
- la seule manière de vérifier les révocations c'est de vérifier auprès d'un serveur de clés auquel on fait confiance (en TLS bien sur!)
Ca rend le concept de clé dans le header ou de lien de clé dans le header totalement bancale, voire dangereux.
# Totalement broken sans authentification de clé
Posté par fcartegnie . En réponse au journal Autocrypt. Évalué à 7.
Envoyer
(削除) la (削除ここまで)une clé à utiliser dans la réponse est une mauvaise idée.Si la clé n'est pas fournie pas un moyen de confiance par le destinataire, rien n'empêche l'attaquant de substituer une autre clé et faire un MITM.
C'est comme envoyer des données à un serveur TLS qui n'aurait pas de CA.
Rien ne prouve que c'est bien le certificat du serveur demandé.
La seule "validation" implicite c'est via le réseau de confiance et les signatures de clé, mais là encore, rien ne prouve que la clé récupérée est la bonne et pas une clé révoquée.
En plus:
- ça bloate les headers en grossissant la clé avec toutes les signatures.
- la seule manière de vérifier les révocations c'est de vérifier auprès d'un serveur de clés auquel on fait confiance (en TLS bien sur!)
Ca rend le concept de clé dans le header ou de lien de clé dans le header totalement bancale, voire dangereux.