Stéphane Bortzmeyer a écrit 645 commentaires

C'est évidemment une excellente idée (Peter St Andre a été très applaudi à la réunion IETF) mais attention, le chiffrement ne protège qu'en transit. Si on a Google Hangouts comme serveur XMPP, la NSA a quand même toutes les infos, puisque c'est Google qui leur donne. Donc, il faut utiliser un serveur XMPP non-PRISM.

Sauf que cela n'a rien à voir et qu'en matière d'ingéniérie, tout mélanger n'est pas la meilleure façon d'avancer.

À noter qu'un deuxième lot est arrivé hier, cette fois tout en ASCII, comprenant des noms comme .CAMERA ou .CLOTHING ou aussi, plus intéressant pour les lecteurs de LinuxFR, .GURU

« Le problème ici c'est ovh.com/fr qui devrait être ovh.fr » Tout dépend du schéma de nommage. "fr" peut être la France (ISO 3166) ou le français (ISO 649). Tout dépend donc si c'étaient des pages spécifiques à la France (monnaie euro, lois françaises) ou spécifiques à la francophonie (textes en français).

Ah non, pas de pensée émue ! C'était une faute énorme, inexcusable ! On le sait depuis longtemps que la liste des TLD varie.

Sans oublier l'exemple http://www.potamochère.fr/ pour tester l'Unicode dans le nom de domaine et dans les liens :-) On note que le CMS de linuxfr le massacre et fait que le lien ne marche pas.

Non, ce n'est pas le but du DNS. http://www.bortzmeyer.org/pourquoi-le-dns.html

« Donner une signification au suffixe, c'est n'importe quoi en terme d'ergonomie. » Savoir qu'on dépend de la loi chinoise (.cn), états-unienne (.com) ou française (.fr) n'a donc aucune importance ?

Et, surtout, qui revient à faire un nommage à plat. Pourquoi diable avoir un système arborescent, avec plusieurs TLD, si c'est pour mettre des règles aussi baroques ?

Aujourd'hui, pour l'écrasante majorité des utilisateurs, l'important n'est pas de fournir une solution techniquement parfaite (surtout contre un adversaire de la taille et de la compétence de la NSA) mais d'augmenter le niveau moyen de sécurité, qui est de quasiment zéro (poste de travail MS-Windows pourri jusqu'au trognon, et données personnelles chez des fournisseurs de cloud en PRISMland). Donc, déjà permettre à M. Michu de mettre ses données sur une machine en France, qu'il contrôle au moins un peu, ce serait un progrès.

« pas envie d'une image disque / système dédié » Le but de Cozy est apparemment de créer un truc simple à administrer, soit pour les gens n'ayant pas d'expertise admin' système Unix, soit pour ceux qui l'ont mais qui n'ont pas le temps. Un système dédié est infiniment plus simple, on sait ce qu'il y a et ce qu'il faut gérer. Installer des trucs en plus, sur des systèmes très variables, cela casse complètement le côté « n'importe qui y arrive en un clic ».

« comment on fait pour le mettre sur un host externe si on sait pas si c'est chiffré correctement ? » Ça, c'est un syndrôme courant en sécurité, et qui est largement responsable du mauvais état de la sécurité de l'Internet. C'est ne pas vouloir une solution tant qu'elle n'est pas 100 % parfaite, y compris contre un attaquant professionnel et déterminé. Aujourd'hui, si on n'est pas Linuxien professionnel à plein temps, on a zéro sécurité : tout est dans le cloud, chez Oncle PRISM. Cozy est un des outils qui pourront permettre d'augmenter la sécurité de tout le monde, pas seulement de celui qui sait utiliser PGP. Alors, oui, un Cozy chez OVH, ce n'est pas une sécurité de niveau militaire. Mais c'est déjà infiniment mieux que tout sur Gmail et Google Docs.

« Je préfère un cloud qui prend 2Go de mémoire vive pour tourner mais qui tourne bien » D'autres donneurs de conseils trouvaient que 512 Mo, c'était scandaleusement élevé…

« tout est dans le client au niveau sécurité du cloud, pas du côté serveur » Euh, les clients se font pirater aussi, il faut en être conscient. C'est évidemment le cas de toutes les machines MS-Windows mais les lecteurs de LinuxFr auraient tort de croire que leur PC Debian ou ArchLinux à la maison est protégé contre toutes les attaques…

Si :-) https://net.educause.edu/edudomain/eligibility.asp

« obliger les entreprises à réserver un nombre toujours plus grand de noms de domaine » Pourquoi « obliger » ? Personne ne les oblige. Certains se croient obligés de le faire mais ils se trompent. Après tout, plus il y aura de TLD, plus, justement, il sera difficile de vouloir enregistrer son nom dans tous les TLD.

« je me demande quelle proportion des noms de domaines sont détenus légitimement (c'est à dire à des fins non crapuleuses ou spéculatives) » Euh, c'est une définition très restrictive de la légitimité. Est légitime uniquement ce que j'approuve :-) Sérieusement, les activités spéculatives (acheter et revendre des noms de domaine) sont légales. On peut les qualifier d'inutiles ou de stupides mais « illégitime », attention, quelle Haute Autorité des Noms de Domaine va considérer si linuxfr.org est un usage légitime du DNS ou pas ?

« mais comment peut-on justifier des doublons .com, .net et .edu, par exemple? » Je n'ai pas bien compris, là. Le DNS est arborescent. linuxfr.org et linuxfr.com sont deux noms différents. Il est tout à fait normal qu'ils soient gérés indépendemment. Sinon, à quoi servirait un espace de nommage arborescent ? Et, pour répondre, .edu est réservé aux universités états-uniennes, contrairement aux deux autres. Donc, si une fac s'appelle stanford.edu et que je m'appelle Joe Stanford, il est normal que je puisse avoir stanford.com. C'est bien le but de l'arborescence.

"Un" bureau d'enregistrement, pas "le". Blackknight n'est pas le seul :-)

Un contenu qui donne faim :-)

Je pinaille un peu mais le premier était .cn en chinois. Le .jeu fait partie d'une série différente, soumise aux règles ICANN (les ccTLD ou Country-code TLD y échappant).

Ah, exact, désolé, je m'avais trompé. Ceci dit, l'algorithme n'est pas tellement détaillé.

Non, le RFC 5321 ne parle pas du tout de cette vérification très contestée (ou d'une autre). Le seul qui la documente est le 7001 http://www.bortzmeyer.org/7001.html

Je me permets d'ajouter deux conseils à ce utile HOWTO : 1) au début, bien regarder le fichier journal (/var/log/mail.log par défaut sur une Debian) pour voir si tout se passe bien. Gérer un serveur sans regarder le journal, c'est être un chirurgien qui ne opère les yeux fermés. 2) tester son serveur avec des auto-répondeurs http://www.bortzmeyer.org/repondeurs-courrier-test.html

Pour SPF, l'enregistrement nommé SPF n'a quasiment jamais été utilisé. Comme noté dans le RFC 6686, qui faisait le bilan de SPF, le type d'enregistrement DNS recommandé est TXT.

http://www.bortzmeyer.org/6686.html

Plutôt Web de données, non ? (Web sémantique : pipeau, Web de données : concret).

Je ne sais pas trop mais, oui, il y a au moins un rapport avec FOAF.

C'est tellement résumé que cela n'a aucun sens (par exemple, ECDSA et RSA sont du chiffrement asymétrique tous les deux et la force de leurs clés est incomparable, à nombre de bits égaux).

Tout à fait, et j'en profite pour signaler cette excellente conférence pour les parisiens :

SSL/TLS, Benjamin Sonntag
associé gérant et directeur technique d'Octopuce,
co-fondateur de La Quadrature du Net

Vendredi 20 septembre 2013, 19h
La Cantine
151 rue Montmartre, Passage des Panoramas (Paris, 2ème arrondissement)

La réponse d'Adrien est excellente (la plupart des failles sont des attaques contre les pratiques - le mot de passe sur un post-it - pas contre les mathématiques). Une précision : 128 bits, c'est vraiment très court pour RSA (il existe des attaques meilleure que la force brute), la taille recommandée est 2048 bits.

En effet, ces articles sont sensationnalistes et souvent faux. (De toute façon, quand quelqu'un dit "crypter" au lieu de "chiffrer", c'est clair qu'il ne connait rien à la crypto.) Du travail de journaliste classique ("Mme Michu ne comprend pas les nuances, il faut simplifier.")

Donc, non, la NSA ne peut pas tout déchiffrer. Néanmoins, ils peuvent faire beaucoup de choses donc il ne faut pas croire non plus que la crypto est une solution magique à tous les problèmes. Par exemple, les logiciels états-uniens ont des portes dérobées et il ne faut donc pas utiliser Windows (mais je pense que pas mal des lecteurs ici le saveient déjà).

Mais si, l'écoutant sait des choses, même avec TLS, comme le fait qu'il y a une communication, combien d'octets sont échangés et même (avec la reprise de session) si ce client était déjà passé.

Le RFC se focalise sur la discrétion des protocoles. La question de la protection du contenu est déjà bien connue, celle des protocoles semble avoir été pas mal négligée.