Le protocole DKIM de signature des courriers
électroniques a une limite. Tant que tout le monde ne signe pas, on ne
peut pas savoir si l'absence de signature est volontaire ou bien est
la conséquence d'une fraude. Le protocole SSP (Signing
Practices Protocol) doit permettre de résoudre ce
problème.
DKIM, normalisé dans le , normalise un mécanisme pour insérer des
signatures cryptographiques dans un
courrier électronique, de façon à en prouver
l'authenticité. Mais le déploiement de DKIM ne sera pas instantané et
n'atteindra peut-être jamais 100 % des serveurs de
messagerie. Si un message arrive sans signature, est-ce
normal car ce domaine ne signe pas, ou bien est-ce une fraude ?
Impossible de le savoir sans connaitre les pratiques de signature du
domaine. Par exemple cisco.com signe tous ses
messages. Mais on ne peut pas connaitre les pratiques de tous les
domaines de l'Internet. Il faut donc un
protocole pour récupérer cette information, SSP, dont ce RFC
donne le cahier des charges.
Le principe de SSP est de fournir un moyen permettant à un
MTA de décider, lorsque le message n'est pas
signé, si cela est suspect ou non. Si SSP indique que
example.net signe toujours et qu'un message
prétendant venir de dupont@example.net n'est pas
signé, le récepteur pourra donc légitimement le traiter avec une
extrême suspicion.
La section 3 du RFC donne divers scénarios d'usage, et la section 4
se penche sur les problèmes de déploiement, un problème difficile pour
toutes les nouvelles technologies. Ainsi, la section 4.2 rappelle que
le gérant d'un domaine peut avoir envie de couvrir également les
sous-domaines (autrement, le méchant qui veut faire croire que son
domaine est example.net n'aurait qu'à envoyer
depuis staff.example.net), la section 4.5 insiste
sur les questions de performance, etc..
La section 5 attaque les exigences proprement dites. Je ne vais pas
les énumérer ici, mais seulement donner quelques exemples :
- 5.1 (4) reprend le scénario d'une attaque sur un sous-domaine et
demande que SSP permette de couvrir les sous-domaines (on note que
cela permettrait au gérant de
.com de définir une
politique pour example.com...).
- 5.2 (3) exige que la charge entrainée par les requêtes SSP soit
bornée (SPF, normalisé dans le , avait été critiqué car son langage, très puissant,
permettait d'exprimer des politiques complètes qui auraient pu mener à
une avalanche de requêtes DNS à chaque message reçu).
- 5.3 (5) veut que la syntaxe des messages soit compréhensible par
un humain et dit, par exemple, que p=unknown est
préférable à p=? (là encore, SPF est sans doute
visé, ses enregistrements étant parfois cryptiques).
- 5.3 (9) exige que l'appel à SSP soit facultatif, si la signature
DKIM est présente et correcte.
SSP a finalement été spécifié dans le , qui utilise le
DNS pour récupérer
des politiques ressemblant, pour un domaine qui signe tout et garantit
que ces signatures ne sont pas invalidés en cours de route, à dkim=discardable.