Perso, je suis pour l'agilité. Mais je pense si c'est introduit, il y aura des demandes incessantes pour ajouter des algos foireux et pour demander que ce soit configurable.
Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.
Sérieusement, si le projet est clair sur le fait que ce sont les développeurs principaux qui choisissent les algos et que toute demande sur ce sujet sera refusée, ça ne pose pas plus de problème que le choix actuel.
D'ailleurs, je ne serais pas surpris que même actuellement, ils reçoivent justement de telles demandes. Ou des demandes d'introduction d'agilité, comme on dit visiblement.
Ce n'est pas aussi magique que ça, il y a un risque de downgrade attack, qu'il faut aussi gérer sans bug.
Bof. Ce n'est pas compliqué, si je comprends bien le problème principal, c'est celui de la mise à jour d'un serveur VPN et de ses clients, qui, avec la conception actuelle, quand le cas se présentera, devra se faire de façon simultanée. Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles, pour que les évolutions ne nécessitent plus une telle parfaite synchronisation : il suffit que le serveur prenne en charge la version actuelle du jeu d'algos crypto et, sur configuration explicite, la précédente.
Scénario :
le serveur est mis à jour, et configuré pour accepter l'ancien jeu d'algos ;
les clients sont avertis qu'ils doivent mettre à jour avant telle date ;
à la date dite, le serveur est configuré pour ne plus accepter l'ancien jeu d'algos.
Sans ça, le scénario serait plutôt :
le serveur n'est pas mis à jour, pour ne pas péter l'intégralité des connexions ;
les clients sont avertis qu'ils doivent mettre à jour exactement à telle date, telle heure ;
(les clients qui mettent à jour trop tôt sont pétés) ;
à la date dite, le serveur est mis à jour ;
(les clients qui n'ont pas mis à jour à temps sont pétés).
Ce scénario, qui est celui choisi par la conception de WireGuard, est juste moins bien que l'autre, pour le service évidemment, mais également pour la sécurité. Parce que si vous observez bien, l'utilisation d'algos obsolètes n'y nécessite même pas d'attaque par dégradation, elle est carrément maintenue par conception, le temps que tout le monde soit prêt à faire une mise à jour synchronisée !
[^] # Re: Une seule suite crypto ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à 6.
Les demandes, ça se gère sans problème, il suffit de les refuser. C'est très facile à automatiser d'ailleurs.
Sérieusement, si le projet est clair sur le fait que ce sont les développeurs principaux qui choisissent les algos et que toute demande sur ce sujet sera refusée, ça ne pose pas plus de problème que le choix actuel.
D'ailleurs, je ne serais pas surpris que même actuellement, ils reçoivent justement de telles demandes. Ou des demandes d'introduction d'agilité, comme on dit visiblement.
Bof. Ce n'est pas compliqué, si je comprends bien le problème principal, c'est celui de la mise à jour d'un serveur VPN et de ses clients, qui, avec la conception actuelle, quand le cas se présentera, devra se faire de façon simultanée. Donc, comme je disais, pas besoin de maintenir un ensemble délirant de protocoles, pour que les évolutions ne nécessitent plus une telle parfaite synchronisation : il suffit que le serveur prenne en charge la version actuelle du jeu d'algos crypto et, sur configuration explicite, la précédente.
Scénario :
Sans ça, le scénario serait plutôt :
Ce scénario, qui est celui choisi par la conception de WireGuard, est juste moins bien que l'autre, pour le service évidemment, mais également pour la sécurité. Parce que si vous observez bien, l'utilisation d'algos obsolètes n'y nécessite même pas d'attaque par dégradation, elle est carrément maintenue par conception, le temps que tout le monde soit prêt à faire une mise à jour synchronisée !