Par contre, je m'inquiète bien plus de l'arrivée des alphabets non latin, et/ou des accents dans les noms de domaines...
Il est vrai qu'il est inquiétant que les russes veulent utiliser l'alphabet cyrillique et les iraniens l'alphabet arabe. Que font Chuck Norris et SuperDupont ?
Blague à part, si l'Internet avait été inventé en Chine, que diriez-vous de devoir taper toutes les adresses avec un bout en chinois à droite. Avec des chinois qui vous expliquent doctement que ce n'est pas si difficile que cela et que c'est dans l'intérêt de la sécurité et de la stabilité ?
Je trouve étonnant que sur un forum de logiciel libre, on lise des réactions aussi primaires contre l'internationalisation, alors que Microsoft fait des efforts pour adapter tous ses logiciels.
par exemple avec une annulation immédiate du domaine en cas de squattage manifeste
C'est sur linuxfr qu'on lit ça ? Eh bien, il ne reste plus qu'à voter un soutien enthousiaste à la loi Hadopi <http://fr.wikipedia.org/wiki/Loi_Hadopi>. « Riposte graduée » au cybersquattage ?
Au fait, jeboycottedanone.com, c'était du cybersquattage ? Pour les avocats de Danone, oui.
C'est curieux qu'il faille apprendre aux lecteurs de linuxfr qu'on ne doit pas faire confiance à ce qui est écrit par des journalistes sur du papier. Seule l'information publiée sur Internet est correcte et à jour et l'ICANN a vite démenti cet interview :
Un peu de bon sens aurait suffi à détecter la traduction ultra-approximative (Paul Twomey ne parle pas français). Certes, l'ICANN est une organisation assez secrète où les vraies décisions sont prises en petit comité et annoncées par suprise mais, là, quand même, l'ICANN qui a toujours été ultra-fidèle au patronat et aux détenteurs de propriété intellectuelle, qui ouvrirait les vannes tout grand à la liberté ? C'était difficilement croyable.
the root server will fit as much as it can within a 512-byte packet and mark the answer as "truncated,"
Ce n'est pas vraiment exact (sauf à utiliser le mot troncation dans un sens très général, alors qu'il a une signification bien précise pour le DNS).
Comme la taille de la section Réponse ou Autorité ne va pas changer (il n'y a toujours que treize serveurs), il n'y aura pas de troncation. Il y aura simplement sélection des enregistrements dans la section Addition, et cette section n'est pas obligatoire.
Donc, le risque n'était pas la troncation, mais le fait que la sélection des colles (les adresses IP des serveurs) pourrait ne laisser que des adresses IPv4 ou bien que des adresses IPv4, ce qui serait ennuyeux pour le client mono-protocole.
L'alternative elle existait déjà dans le standard dns depuis fort longtemps ;)
L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.
La complexité par rapport à quoi ? La personne qui parle de complexité à propos d'OpenID n'a manifestement jamais essayé de comprendre Cardspace ou Shibboleth...
> mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à
> longtemps fait pâle figure.
Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?
Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
Je me doutais que la discussion allait surtout consister en remarques du genre "ya aussi XYZ 1.0 qui est super bien" :-)
Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.
Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).
Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.
Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
> Certains MTA ajoutent des champs au mail permettant de savoir quel
> était le From de l'enveloppe. Avec Postfix, il semble que ce soit la
> premiere ligne des en-tetes :
> "From titi@toto.com Mon Sep 6 15:10:22 2004" par exemple.
Non, ce From sans : à la fin est spécifique au format "mbox" et dépend donc du MDA (procmail, local, deliver, etc), pas du MTA (Postfix, sendmail, etc). Si vous utilisez le format Maildir, vous ne l'aurez pas.
Quant cette information est mise dans un en-tête, c'est Return-Path:.
> Pour un système anti-spam, analyser les en-tetes du mail est
> beaucoup trop cher,
Ce n'est pas du tout une question de coût (SpamAssassin fait des analyses bien plus complexes), c'est simplement que le FROM de l'enveloppe n'a pas les mêmes propriétés que le From: des en-têtes. Il existe plusieurs identités dans le courrier et les différents protocoles ne vérifient pas les mêmes. Le SenderID actuellement en cours de discussion offrira le choix de l'identité à tester.
>Le sender-id se base sur authentification IP et les DNS, deux technologies >maintes fois critiquees et sujet a de nombreuse attaques
...
> Une bonne analyse ici des divers problemes du SENDER ID:
> http://www.esecurityplanet.com/views/article.php/3398431(...)
N'exagérons rien : il n'y a rien de commun entre la facilité d'une usurpation d'identité via le protocole SMTP et la facilité d'usurpation d'une adresse IP ou même d'une réponse DNS.
Dans le premier cas, c'est trivial et déjà largement mis en oeuvre.
Dans le deuxième, c'est d'un autre ordre de grandeur ! Les gens qui, comme l'auteur de l'article cité disent que c'est trivial n'ont manifestement jamais essayé.(Certaines bogues qui rendaient ces attaques possibles ont été bouchées depuis longtemps, les noyaux Unix ont des numéros de séquence TCP difficiles à deviner, BIND n'accepte plus les réponses martiennes, etc.)
> si il faut vraiment une solution technique, je suis plutot pour des solutions du > cote du cryptage/signature.
Ces solutions sont spécifiées et implémentées depuis dix ou quinze ans. Pourquoi ne sont-elles toujours pas déployées si elles sont si miraculeuses ?
L'article en question est entièrement bâti sur une "étude" de MXlogic, une boîte qui... vend des solutions anti-spam et qui a donc tout intérêt à débiner ses concurrents.
Les chiffres donnés ne correspondent pas à ce que l'on mesure, par exemple sur le banc de test SPF de l'AFNIC.
La discussion ayant montré beaucoup d'ignorance sur les techniques SPF et SenderID et "l'ignorance ne pouvant pas être pardonnée, seulement guérie" (Confucius), j'oublie toute modestie et j'attire l'attention sur mes documents : un article d'introduction à SPF et SenderID , visant un public non-technique et des transparents d'un cours plus technique.
> J'ai toujours trouvé ça énorme de donner comme ça des /48 à tout va.
Le RFC 3177 explique fort bien pourquoi. En résumé, c'est parce que toute autre méthode d'affectation nécessiterait une bureaucratie pour décider de la taille de l'affectation, taille qui pourrait être remise en cause à chaque changement de FAI.
Il est plus simple de donner un /48 sans discussion.
> Et un flicage ultra-simplifié. Une IP fixe et immuable par personne.
Bon, ça, c'est du baratin pur et simple, je l'ai déjà expliqué à Antoine mais, comme il s'obstine à propager la même légende, reprenons les faits :
1) Une (une seule et pas celle que j'utilise chez moi, par exemple) des méthodes d'affectation des adresses IPv6 utilise l'adresse MAC (celle de la carte Ethernet). Elle permet donc potentiellement de suivre une machine (pas une personne) à la trace, même lorsqu'elle change de FAI (mais pas lorsqu'elle change de carte Ethernet).
2) Si on n'aime pas cela, on peut toujours choisir un autre mode d'affectation. Il y en a un qui a les mêmes propriétés (automatique et sans état) et qui est décrite dans le RFC 3041 (et c'est l'option par défaut dans le noyau Linux).
> De même que la pénurie d'IPv4 sous moins de 10 ans est largement
> éxagérée.
La pénurie existe déjà : sinon, on n'aurait pas besoin d'autant d'employés dans les RIR (Regional Internet Registries, comme le RIPE-NCC) chargés d'examiner les justifications, et de les approuver ou de les rejeter.
Si un LIR demande aujourd'hui des adresses IPv4, il doit justifier chaque affectation (même un /28), avec paperasse à l'appui. Avec IPv6, une fois obtenue sa première allocation, il est tranquille. Ce n'est pas une pénurie, ça ? C'est même du rationnement.
[^] # Re: Je le fais déjà
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN libère les extensions de domaines. Évalué à 2.
.dom
Ils sont peut-être courants mais très dangereux à utiliser. Ils n'ont jamais été normalisés et peuvent donc demain être délégués à un vrai TLD.
RFC 2606 <http://www.bortzmeyer.org/2606.html>
Seul .example est réservé et sûr. Mais pas prévu pour cet usage. Pourquoi ne pas utiliser un vrai domaine ?
[^] # Re: Pas si simple que ça...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN libère les extensions de domaines. Évalué à 7.
Il est vrai qu'il est inquiétant que les russes veulent utiliser l'alphabet cyrillique et les iraniens l'alphabet arabe. Que font Chuck Norris et SuperDupont ?
Blague à part, si l'Internet avait été inventé en Chine, que diriez-vous de devoir taper toutes les adresses avec un bout en chinois à droite. Avec des chinois qui vous expliquent doctement que ce n'est pas si difficile que cela et que c'est dans l'intérêt de la sécurité et de la stabilité ?
Je trouve étonnant que sur un forum de logiciel libre, on lise des réactions aussi primaires contre l'internationalisation, alors que Microsoft fait des efforts pour adapter tous ses logiciels.
[^] # Re: Prix?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN libère les extensions de domaines. Évalué à 7.
C'est sur linuxfr qu'on lit ça ? Eh bien, il ne reste plus qu'à voter un soutien enthousiaste à la loi Hadopi <http://fr.wikipedia.org/wiki/Loi_Hadopi>. « Riposte graduée » au cybersquattage ?
Au fait, jeboycottedanone.com, c'était du cybersquattage ? Pour les avocats de Danone, oui.
# Fausse information, pas la peine de perdre du temps à la commenter
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN libère les extensions de domaines. Évalué à 5.
http://www.mailclub.info/article.php3?id_article=807
Un peu de bon sens aurait suffi à détecter la traduction ultra-approximative (Paul Twomey ne parle pas français). Certes, l'ICANN est une organisation assez secrète où les vraies décisions sont prises en petit comité et annoncées par suprise mais, là, quand même, l'ICANN qui a toujours été ultra-fidèle au patronat et aux détenteurs de propriété intellectuelle, qui ouvrirait les vannes tout grand à la liberté ? C'était difficilement croyable.
[^] # arstechnica ne s'est pas bien exprimé
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche IPv6 à la racine des DNS. Évalué à 1.
Ce n'est pas vraiment exact (sauf à utiliser le mot troncation dans un sens très général, alors qu'il a une signification bien précise pour le DNS).
Comme la taille de la section Réponse ou Autorité ne va pas changer (il n'y a toujours que treize serveurs), il n'y aura pas de troncation. Il y aura simplement sélection des enregistrements dans la section Addition, et cette section n'est pas obligatoire.
Donc, le risque n'était pas la troncation, mais le fait que la sélection des colles (les adresses IP des serveurs) pourrait ne laisser que des adresses IPv4 ou bien que des adresses IPv4, ce qui serait ennuyeux pour le client mono-protocole.
Avec EDNS0, le problème disparait.
Le rapport complet du SSAC pour ceux qui ont le courage : http://www.icann.org/committees/security/sac018.pdf
[^] # EDNS0, pas TCP
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche IPv6 à la racine des DNS. Évalué à 2.
L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.
# Complexe par rapport à quoi ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche OpenID 2.0 est arrivé. Évalué à 2.
[^] # Re: Personne n'y met vraiment du sien
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Communiqué du RIPE sur IPv6. Évalué à 2.
Peut-être parce que ça ne rapporte rien à celui qui s'y met alors que le coût de ne pas s'y mettre est partagé par tous ? http://www.bortzmeyer.org/ipv6-et-l-echec-du-marche.html
[^] # Re: Diverses remarques
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 2.
> longtemps fait pâle figure.
Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?
Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
[^] # Re: Inscription
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 2.
http://www.parinux.org/news/news-req.html?news=245
et je suppose (mais je ne suis pas à Parinux) qu'on peut venir informellement.
[^] # Re: Y'a aussi Bazaar 2
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 8.
Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.
Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).
Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.
Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
[^] # Re: Explication
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
> était le From de l'enveloppe. Avec Postfix, il semble que ce soit la
> premiere ligne des en-tetes :
> "From titi@toto.com Mon Sep 6 15:10:22 2004" par exemple.
Non, ce From sans : à la fin est spécifique au format "mbox" et dépend donc du MDA (procmail, local, deliver, etc), pas du MTA (Postfix, sendmail, etc). Si vous utilisez le format Maildir, vous ne l'aurez pas.
Quant cette information est mise dans un en-tête, c'est Return-Path:.
> Pour un système anti-spam, analyser les en-tetes du mail est
> beaucoup trop cher,
Ce n'est pas du tout une question de coût (SpamAssassin fait des analyses bien plus complexes), c'est simplement que le FROM de l'enveloppe n'a pas les mêmes propriétés que le From: des en-têtes. Il existe plusieurs identités dans le courrier et les différents protocoles ne vérifient pas les mêmes. Le SenderID actuellement en cours de discussion offrira le choix de l'identité à tester.
[^] # Re: Deja inutile ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
...
> Une bonne analyse ici des divers problemes du SENDER ID:
> http://www.esecurityplanet.com/views/article.php/3398431(...)
N'exagérons rien : il n'y a rien de commun entre la facilité d'une usurpation d'identité via le protocole SMTP et la facilité d'usurpation d'une adresse IP ou même d'une réponse DNS.
Dans le premier cas, c'est trivial et déjà largement mis en oeuvre.
Dans le deuxième, c'est d'un autre ordre de grandeur ! Les gens qui, comme l'auteur de l'article cité disent que c'est trivial n'ont manifestement jamais essayé.(Certaines bogues qui rendaient ces attaques possibles ont été bouchées depuis longtemps, les noyaux Unix ont des numéros de séquence TCP difficiles à deviner, BIND n'accepte plus les réponses martiennes, etc.)
> si il faut vraiment une solution technique, je suis plutot pour des solutions du > cote du cryptage/signature.
Ces solutions sont spécifiées et implémentées depuis dix ou quinze ans. Pourquoi ne sont-elles toujours pas déployées si elles sont si miraculeuses ?
[^] # Re: Deja inutile ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
L'article en question est entièrement bâti sur une "étude" de MXlogic, une boîte qui... vend des solutions anti-spam et qui a donc tout intérêt à débiner ses concurrents.
Les chiffres donnés ne correspondent pas à ce que l'on mesure, par exemple sur le banc de test SPF de l'AFNIC.
# Introduction et transparents sur SPF et SenderID
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 3.
http://www.generic-nic.net/formation/lmap/(...)
[^] # Re: À quand l'utilisation chez les FAI ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 3.
Le RFC 3177 explique fort bien pourquoi. En résumé, c'est parce que toute autre méthode d'affectation nécessiterait une bureaucratie pour décider de la taille de l'affectation, taille qui pourrait être remise en cause à chaque changement de FAI.
Il est plus simple de donner un /48 sans discussion.
[^] # Re: Traçage
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 2.
Bon, ça, c'est du baratin pur et simple, je l'ai déjà expliqué à Antoine mais, comme il s'obstine à propager la même légende, reprenons les faits :
1) Une (une seule et pas celle que j'utilise chez moi, par exemple) des méthodes d'affectation des adresses IPv6 utilise l'adresse MAC (celle de la carte Ethernet). Elle permet donc potentiellement de suivre une machine (pas une personne) à la trace, même lorsqu'elle change de FAI (mais pas lorsqu'elle change de carte Ethernet).
2) Si on n'aime pas cela, on peut toujours choisir un autre mode d'affectation. Il y en a un qui a les mêmes propriétés (automatique et sans état) et qui est décrite dans le RFC 3041 (et c'est l'option par défaut dans le noyau Linux).
[^] # Re: ne pas confondre ce qu'on pourrait faire et ce que l'on peut faire
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 3.
> éxagérée.
La pénurie existe déjà : sinon, on n'aurait pas besoin d'autant d'employés dans les RIR (Regional Internet Registries, comme le RIPE-NCC) chargés d'examiner les justifications, et de les approuver ou de les rejeter.
Si un LIR demande aujourd'hui des adresses IPv4, il doit justifier chaque affectation (même un /28), avec paperasse à l'appui. Avec IPv6, une fois obtenue sa première allocation, il est tranquille. Ce n'est pas une pénurie, ça ? C'est même du rationnement.
[^] # Re: On va bien s'amuser!!!!!
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 2.
Bien sûr que si : il y en a même quatre (cf. http://www.root-servers.org/(...)) mais l'ICANN ne les annonce pas.