A quand le chiffrement obligatoire des emails ?

[Gros biscuit]

Bonjour quelle est votre question, qu'attendez vous du forum et de Que Choisir en particulier ?

Bonjour.
La question est indiquée dans le titre de la discussion.
Le but d'un forum est de discuter et dans le cas présent de consommation vu que tel est le sujet du forum.

[Sauvegarde]

Bonjour quelle est votre question, qu'attendez vous du forum et de Que Choisir en particulier ?

Bonjour.
La question est indiquée dans le titre de la discussion.
Le but d'un forum est de discuter et dans le cas présent de consommation vu que tel est le sujet du forum.

Votre question est donc de savoir à quelle date les e-mails seront obligatoirement chiffrés, ou bien s’agit-il plutôt d’une doléance visant à demander que le chiffrement des e-mails devienne obligatoire ?

Si votre question est de savoir à quelle date le chiffrement des e-mails deviendra obligatoire, la réponse semble être : aucune date n’est actuellement prévue.

La Commission européenne indique d’ailleurs que la mise en œuvre des standards de sécurisation du courrier électronique n’est actuellement rendue obligatoire ni par les protocoles eux-mêmes ni par un cadre juridique général.

Votre sujet est-il donc une demande d’information sur une éventuelle échéance réglementaire, ou plutôt une doléance/proposition pour que le chiffrement des e-mails devienne obligatoire ?

[Gros biscuit]

La doléance est déjà portée à l'IEFT, et effectivement l'espoir demeure dans une obligation réglementaire, comme l'UE a déjà réglementé pour infléchir des usages d'internet, tel le RGPD, et autres évolutions. Je ne crois pas avoir lu un tel projet dans le Digital service act mais dans la complexité de ces volontés, j'ai peut être omis un texte qui viserait à cela.

[Sauvegarde]

OK, je comprends mieux votre question.

Dans ce cas, le DSA ne me semble effectivement pas être le texte à regarder en priorité. Les courriels et messageries privées ne relèvent d'ailleurs pas, en tant que communications interpersonnelles, de la définition des plateformes en ligne du DSA.

En revanche, NIS2 contient déjà des dispositions relatives à la cryptographie et au chiffrement. Son considérant 98 va même jusqu'à préciser que, lorsque cela est nécessaire, le chiffrement, notamment de bout en bout, devrait pouvoir être imposé à certains fournisseurs de services de communications électroniques.

Mais sauf texte que je n'aurais pas trouvé, je ne vois actuellement aucune disposition européenne prévoyant de rendre obligatoire le chiffrement de bout en bout de l'ensemble des e-mails, et encore moins une date prévue pour cela.

Petite nuance également concernant l'IETF : elle peut élaborer les standards techniques permettant ce chiffrement, mais elle ne peut pas en imposer l'usage. Ses standards sont volontaires. Pour rendre le chiffrement obligatoire, il faudrait donc effectivement passer par une obligation réglementaire ou législative.

[Gros biscuit]

Merci pour votre précision.

A mon sens, l'IEFT pourrait faire évoluer le standard des emails d'un point de vue technique en l'absence de contrainte réglementaire afin de l'obliger à supporter le chiffrement du contenu des emails, et ne plus relayer via les serveurs SMTP les emails non chiffrés selon la norme actuelle.
C'est pour cela que j'évoquais les deux leviers : l'un réglementaire, l'autre par l'autorité technique.

[Sauvegarde]

Merci pour votre précision.

A mon sens, l'IEFT pourrait faire évoluer le standard des emails d'un point de vue technique en l'absence de contrainte réglementaire afin de l'obliger à supporter le chiffrement du contenu des emails, et ne plus relayer via les serveurs SMTP les emails non chiffrés selon la norme actuelle.
C'est pour cela que j'évoquais les deux leviers : l'un réglementaire, l'autre par l'autorité technique.

Je comprends mieux votre distinction entre les deux leviers, et sur le principe je vous rejoins : l’IETF pourrait parfaitement faire évoluer les standards techniques et définir qu’un serveur conforme à une nouvelle norme ne doit plus relayer certains messages non chiffrés.

Je mettrais simplement une nuance sur le terme « autorité technique ». L’IETF peut définir ce qu’une implémentation conforme DOIT ou NE DOIT PAS faire, mais elle ne peut pas obliger les fournisseurs de messagerie et les éditeurs à adopter cette nouvelle version du standard. L’IETF précise d’ailleurs elle-même que ses standards sont d’adoption volontaire et qu’elle ne contrôle pas Internet.

Et finalement, le problème ne semble pas tellement être l’absence de normes permettant le chiffrement du contenu : S/MIME et PGP/MIME/OpenPGP sont déjà normalisés depuis longtemps.

L’IETF pourrait donc théoriquement aller un cran plus loin en disant : « désormais, un MTA conforme doit refuser un message dont le contenu n’est pas cryptographiquement protégé ». Mais il resterait alors le problème majeur du déploiement et surtout de la gestion des clés : comment le logiciel de l’expéditeur obtient-il automatiquement et de façon fiable la clé publique du destinataire ?

C’est là, à mon avis, que se situe aujourd’hui beaucoup plus le verrou technique que dans SMTP lui-même.

On a d’ailleurs déjà un exemple intéressant avec REQUIRETLS (RFC 8689) : l’IETF a prévu un mécanisme permettant d’exiger le chiffrement TLS sur le trajet SMTP et de faire échouer l’envoi si cette exigence ne peut pas être respectée. Mais son efficacité dépend là encore de son adoption par les serveurs concernés.

[Gros biscuit]

Tout à fait, cela serait un très gros chantier logiciel, entre le développement, aussi bien des serveurs que des clients (logiciels, webmail, applicatifs intégrés dans les solutions professionnelles de générations d'emails...).

Vous avez raison de rappeler que l'email n'est qu'une couche applicative sur les autres couches réseau et que dans le cas présent il s'agit de la couche 7 selon le modèle OSI qui verrait la norme modifiée s'appliquer, n'empêchant pas techniquement de continuer d'utiliser des solutions autres ne répondant pas à cette norme à ce niveau là.

[Gros biscuit]

Dans un autre sujet de discussion,'Sauvegarde' me dit :

Sur ce point, votre remarque me paraît beaucoup plus intéressante juridiquement.

Je pourrais peut-être illustrer le contraire par l'exemple suivant.
Prenons le cas des professions soumises à secret professionnel.
Ils envoient des emails "en clair" à un destinataire, confrère ou patient/client, la plupart du temps par méconnaissance technique. Autant les CGU de leur prestataire email leur convient dans l'espoir que l'hébergeur fasse bien ce qui est écrit sur le contrat, autant celle à l'autre bout de la chaine ne sont pas compatibles avec ses obligations (RGPD, traitement automatisé des données...) car le destinataire a peut être un prestataire email domicilié dans un pays moins regardant.

Certes dans le cas présent, c'est un défaut de formation de l'expéditeur et du destinataire ne pas avoir installé des technologies optionnelles, et vérifier à ne pas envoyer en l'absence de cette précaution complémentaire, alors que l'avocat ou le médecin n'enverraient pas leur courrier ou ordonnance sans enveloppe par La Poste (même si cela est faussé au niveau du raisonnement, l'enveloppe n'étant qu'un scellé et non un chiffrement).

[Sauvegarde]

Dans un autre sujet de discussion,'Sauvegarde' me dit :

Sur ce point, votre remarque me paraît beaucoup plus intéressante juridiquement.

Je pourrais peut-être illustrer le contraire par l'exemple suivant.
Prenons le cas des professions soumises à secret professionnel.
Ils envoient des emails "en clair" à un destinataire, confrère ou patient/client, la plupart du temps par méconnaissance technique. Autant les CGU de leur prestataire email leur convient dans l'espoir que l'hébergeur fasse bien ce qui est écrit sur le contrat, autant celle à l'autre bout de la chaine ne sont pas compatibles avec ses obligations (RGPD, traitement automatisé des données...) car le destinataire a peut être un prestataire email domicilié dans un pays moins regardant.

Certes dans le cas présent, c'est un défaut de formation de l'expéditeur et du destinataire ne pas avoir installé des technologies optionnelles, et vérifier à ne pas envoyer en l'absence de cette précaution complémentaire, alors que l'avocat ou le médecin n'enverraient pas leur courrier ou ordonnance sans enveloppe par La Poste (même si cela est faussé au niveau du raisonnement, l'enveloppe n'étant qu'un scellé et non un chiffrement).

Oui, là votre exemple me paraît effectivement beaucoup plus parlant : pour certaines catégories de données, notamment médicales ou couvertes par le secret professionnel, la messagerie électronique ordinaire pose réellement un problème de sécurité.

La CNIL elle-même indique que les canaux grand public, dont la messagerie électronique, ne constituent généralement pas sans mesures complémentaires un moyen suffisamment sûr pour transmettre certaines données personnelles et recommande notamment de chiffrer les pièces sensibles.

Pour les données de santé, c'est encore plus explicite : la CNIL demande un niveau de sécurité adapté à leur sensibilité et cite le chiffrement fort. C'est d'ailleurs précisément pour cela qu'existe en France l'espace MSSanté.

Mais il y a, je crois, une distinction importante avec votre proposition initiale.

Sécuriser un échange n'implique pas nécessairement un chiffrement de bout en bout du contenu selon le modèle PGP/S/MIME. Une messagerie peut cumuler TLS entre les différents maillons, authentification forte, serveurs maîtrisés, contrôle des destinataires, hébergement sécurisé, etc., tout en laissant techniquement le contenu accessible aux serveurs qui le traitent.

MSSanté en est justement un bon exemple : son usage permet aux professionnels de santé de satisfaire leurs obligations de sécurité, alors que l'utilisation de MSSanté n'est elle-même pas légalement obligatoire en tant que telle. C'est le niveau de protection adapté au risque qui est imposé.

Même logique dans le RGPD : l'article 32 cite le chiffrement parmi les mesures envisageables, mais ne décrète pas « toute donnée personnelle ou confidentielle doit être chiffrée de bout en bout ».

Donc votre exemple me semble plutôt démontrer qu'il existe des situations dans lesquelles **une messagerie ordinaire sans mesures supplémentaires est insuffisante**, ce sur quoi je vous rejoins.

En revanche, il ne démontre pas encore, à mon sens, qu'il faudrait modifier le standard SMTP pour que tout serveur refuse par principe tout message dont le contenu n'est pas chiffré de bout en bout.

Et cela nous ramène au problème technique évoqué plus haut : pour rendre cela universel et transparent, il faudrait résoudre non seulement le chiffrement lui-même — que nous savons faire depuis longtemps — mais surtout l'identification fiable du destinataire, la découverte et la gestion automatique de ses clés, leur révocation, leur renouvellement, la récupération en cas de perte, les échanges automatisés, les listes de diffusion, etc.

C'est probablement là que se situe le véritable chantier.

[Gros biscuit]

Ma mère écrit par email à son frère que le voisin a un cancer de la peau, constitue une donnée médicale saisie sans le consentement de l'intéressé qui ne passe pas par le réseau MSSanté.