Journal SSH3 n’est pas la suite d’SSH

Posté par  . Licence CC By‑SA.
Étiquettes :
30
30
sept.
2025

J’attends depuis l’arrivée du protocole QUIC, son utilisation dans SSH. En effet l’utilisation des channels me parait très intéressant pour par exemple n’utiliser qu’une seule connexion pour transférer des fichiers et garder son shell.

J’étais donc très intéressé quand j’ai vu une news de korben.info sur SSH3 https://korben.info/ssh3-serveurs-invisibles-http3-quic-revolution.html

J’ai par contre vite été surpris que ça parle de faire du SSH over HTTP/3. Les sources qu’il donne son un lien IETF https://datatracker.ietf.org/doc/draft-michel-ssh3/ et du code https://github.com/francoismichel/ssh3.

On se calme (…)

FFV1, un format vidéo sans perte et libre, normalisé à l'IETF

Posté par  (site web personnel) . Édité par antistress, orfenor, esdeem, Olivier Jeannet, Stéphane Bortzmeyer, Anonyme, BAud, Benoît Sibaud, Yves Bourguignon, Pierre Jarillon, Scoubidouhoua, tisaac, Julien Jorge, Bruno Ethvignot et Ltrlg. Modéré par Pierre Jarillon.
Étiquettes :
115
24
août
2021
Audiovisuel

Si la compression vidéo sans perte est moins tendance que celle avec perte, elle reste utile dans certains domaines (par exemple l’archivage, que ce soit pour son stockage ou sa transmission, qu’il concerne des enregistrements de procès importants pour l’histoire ou le dernier blockbuster à la mode).
L’Internet Engineering Task Force (IETF) avait déjà normalisé des formats de compression avec perte (Opus, pour l'audio), mais pas encore de format sans perte : c'est à présent chose faite, cette fois-ci en matière de vidéo, avec la normalisation de FFV1 sous le doux nom de RFC 9043.

logo IETF

Joyce Reynolds est morte :-(

Posté par  (site web personnel, Mastodon) . Édité par Benoît Sibaud. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
46
31
déc.
2015
Internet

Joyce Reynolds vient de mourir, de maladie. Elle était l’auteure de nombreux RFC (demande de commentaires), dont ceux sur le protocole telnet. Elle était aussi co-éditrice des RFC à la grande époque (celle de Jon Postel). Comme elle signait « J. K Reynolds », des tas de gens qui cherchaient à contacter « l’auteur de telnet » étaient surpris en la voyant « mais non, je cherche un technicien ». Elle avait aussi travaillé sur plein d’autres trucs des débuts de l’Internet (comme le TLD .us) et de l’IETF.

Journal Joyce Reynolds est morte :-(

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
55
30
déc.
2015
Ce journal a été promu en dépêche : Joyce Reynolds est morte :-(.

Joyce Reynolds vient de mourir, de maladie. Elle était l’auteur de nombreux RFC, dont ceux sur telnet. Elle était aussi co-éditeur des RFC à la grande époque (celle de Jon Postel). Comme elle signait « J. K Reynolds », des tas de gens qui cherchaient à contacter « l’auteur de telnet » étaient surpris en la voyant « mais non, je cherche un technicien ». Elle avait aussi travaillé sur plein d’autres trucs des débuts de l’Internet (comme le TLD .us) et de l’IETF.

Une fameuse (…)

Publication de la RFC « DNS et vie privée »

Posté par  (site web personnel, Mastodon) . Édité par Benoît Sibaud, bubar🦥, BAud, M5oul et palm123. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
42
13
sept.
2015
Internet

La demande de commentaires (RFC) 7626, « DNS Privacy Considerations », a été publiée fin août par l'IETF (entité qui élabore les standards d'Internet). Elle est issue des travaux du « groupe de travail IETF sur DNS et vie privée » évoqué précédemment. Ce document se focalise sur les risques encourus par les usagers pour leur vie privée, dans l'usage actuel des services de résolutions de noms.

Les groupes de travail IETF sont maintenant bien occupés aux futures solutions (minimisation des données envoyées et chiffrement).

Le risque d'une surveillance particulière pour un titulaire de zone est discuté via les RFC 5936 & 5155. Les risques autres que ceux concernant la vie privée (comme du cache poisoning) sont hors-sujet ici. Nous considérons ici les risques pour la vie privée d'une surveillance générale ou plus précise.

« Ce[tte] RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973 (…). Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées (…) et les rendre plus résistantes à l'écoute, via le chiffrement. ».

Journal Le RFC "DNS et vie privée" a été publié

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
33
28
août
2015
Ce journal a été promu en dépêche : Publication de la RFC « DNS et vie privée ».

Voici la suite du journal « Création du groupe de travail IETF sur DNS et vie privée ». Le RFC 7626, « DNS Privacy Considerations » est désormais publié. Il décrit le problème. J'espère qu'il est lisible par des gens qui ne sont pas les top-experts du DNS.

Les groupes de travail IETF sont maintenant bien occupés aux futures solutions (minimisation des données envoyées et chiffrement).

Contribuez au Référentiel Général d'Interopérabilité v2.0 français

Posté par  . Édité par ZeroHeure, Benoît Sibaud, Nÿco, palm123 et Nils Ratusznik. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
26
29
avr.
2015
Technologie

L'État français modernise son Référentiel Général d'Interopérabilité (RGI). Comme il n'a pas la science infuse, il demande aux spécialistes du terrain de donner leur avis sur le brouillon de ce qui deviendra la version 2.0 : appel public à commentaires RGI.

Attention ! La période de consultation se finit le 15 mai.

Si vous êtes expert(e) dans un domaine ou bien simple utilisateur et que vous souhaitez promouvoir l'interopérabilité (dans la mesure du possible avec un format ouvert et documenté) et ne pas vous retrouver sur Linux/*BSD à devoir lire des formats propriétaires et fermés venant de l'administration mais inutilisables, alors votre avis est le bienvenu.

Notez que l'AFUL et l'April ont ouvert un framapad pour coordonner tout cela.

À noter aussi une consultation de l'Autorité de la Concurrence : voir en fin de seconde partie de la dépêche.

Journal Création du groupe de travail IETF sur « DNS et vie privée »

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
27
20
oct.
2014

L'IETF (l'organisme qui fait les normes techniques de l'Internet) vient de créer le groupe de travail DPRIVE (« DNS private exchange »), consacré au travail sur l'amélioration de la vie privée pour les utilisateurs du DNS (eh oui, chaque fois que vous vous connectez sur http://www.siteporno.fr/, des tas de gens sont au courant, pas uniquement la NSA et votre FAI).

La charte du groupe de travail, avec les échéances, est en ligne.

Le groupe n'a pas encore de documents mais (…)

Journal L'IETF se lance dans la lutte contre l'espionnage

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
43
7
nov.
2013
Ce journal a été promu en dépêche : L’IETF se lance dans la lutte contre l’espionnage.

Des tas de gens et d'organisations ont été secoués par les révélations du héros Edward Snowden concernant l'ampleur de l'espionnage réalisé par la NSA (et, certainement, par bien d'autres organisations). Bien sûr, les experts en sécurité savaient depuis longtemps mais ils avaient le plus grand mal à se faire entendre, les dirigeants et les utilisateurs préféraient se moquer de ces experts, en les qualifiant de paranoïaques. Les révélations de Snowden ont montré que les paranoïaques ne l'étaient en fait pas (…)

Journal SPF désigné vainqueur dans le match contre Sender ID

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
42
21
juil.
2012

L'IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d'authentification faible du courrier électronique par le biais de la publication dans le DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, SPF et Sender ID. Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender ID. Six ans après est publié le RFC 6686 qui conclut enfin officiellement (…)

Journal RFC 6569 : Guidelines for Development of an Audio Codec Within the IETF

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
26
27
mar.
2012

Constatant l'absence d'un codec entièrement libre (pas plombé par des brevets, pas contrôlé par une société unique, implémentable en logiciel libre), l'IETF s'est lancée dans la spécification d'un codec satisfaisant. Le RFC 6366 donnait le cahier des charges technique du futur codec (le produit final) et ce nouveau RFC, le 6569, donne les considérations portant sur le processus de développement (processus déjà bien entamé) : méthodologie d'évaluation des propositions, mécanisme de vérification de la compatibilité des implémentations, questions de propriété intellectuelle. (…)

Journal Des (bonnes) nouvelles pour tzdata

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
27
17
oct.
2011

Il y a une dizaine de jours, on pouvait lire ici même que la base "tzdata" était menacée du fait des poursuites juridiques de la part d'un éditeur contre le groupe de volontaires maintenant cette base.

Les problèmes juridiques sont toujours d'actualité, mais la gestion de la base est maintenant reprise par l'ICANN à la demande de l'IETF nous apprend un article du Register.

Cela permet d'avoir un peu plus d'espoir pour l'avenir de tzdata, d'autant que (…)