From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ...fer_Protocol_NNTP_Extension_for_Compression.txt | 165 +++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 RFC_8054_Network_News_Transfer_Protocol_NNTP_Extension_for_Compression.txt (limited to 'RFC_8054_Network_News_Transfer_Protocol_NNTP_Extension_for_Compression.txt') diff --git a/RFC_8054_Network_News_Transfer_Protocol_NNTP_Extension_for_Compression.txt b/RFC_8054_Network_News_Transfer_Protocol_NNTP_Extension_for_Compression.txt new file mode 100644 index 0000000..75592ae --- /dev/null +++ b/RFC_8054_Network_News_Transfer_Protocol_NNTP_Extension_for_Compression.txt @@ -0,0 +1,165 @@ +Titre: RFC 8054: Network News Transfer Protocol (NNTP) Extension for Compression +Auteur: +Date: Thu 26 Jan 2017 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/8054.html + +Ce nouveau RFC définit un mécanisme standard de compression des news échangées +en NNTP, sur Usenet. + +NNTP, normalisé dans le RFC 3977 est un protocole gourmand en débit. Comprimer +les données transmises est donc très souhaitable. C'est aussi un protocole très +ancien, ce qui se voit dans certaines références du RFC, comme l'allusion à la +compression PPP du RFC 1962 ou bien à la compression par modem comme V42bis :-) + +Mais, malgré ce besoin de compression, il n'y avait pas encore de solution +standard en NNTP. Un certain nombre de mécanismes non-standards avaient été +déployés avec des noms comme XZVER, XZHDR, XFEATURE COMPRESS, ou MODE COMPRESS. +Outre l'absence de normalisation, ils souffraient de ne comprimer que les +réponses du serveur de news. + +Compte-tenu du déploiement de plus en plus fréquent de TLS, pour assurer la +confidentialité des échanges, il avait été envisagé à une époque de compter sur +le mécanisme de compression de TLS (RFC 4642). Celui-ci présente +malheureusement des dangers, qui fait que son usage est déconseillé dans +beaucoup de cas (section 3.3 du RFC 7525, et section 2.6 du RFC 7457). En +outre, la solution de ce RFC bénéficie de davantage de souplesse : elle peut +par exemple n'être activée qu'une fois l'authentification faite, pour éviter +les attaques comme CRIME (voir aussi les sections 2.2.2 et 7 de notre RFC, pour +tous les détails de sécurité). + +Pour assurer l'interopérabilité maximale, un seul algorithme de compression est +défini, et il est, logiquement, obligatoire. Cela garantit qu'un client et un +serveur NNTP auront toujours cet algorithme en commun. Il s'agit de Deflate, +normalisé dans le RFC 1951. + +(Un petit point qui n'a rien à voir avec NNTP et la compression : comme le +demandait l'Internet-Draft qui a donné naissance à notre RFC, j'ai mis un +accent à la première lettre du nom d'un des auteurs, ce qui n'est pas possible +dans le RFC original, cela ne le sera que lorsque le RFC 7997 sera mis en +œuvre.) + +Maintenant, les détails techniques (section 2 du RFC). Le serveur doit annoncer +sa capacité à comprimer en réponse à la commande CAPABILITIES. Par exemple (C = +client, S = serveur) : + +[C] CAPABILITIES +[S] 101 Capability list: +[S] VERSION 2 +[S] READER +[S] IHAVE +[S] COMPRESS DEFLATE SHRINK +[S] LIST ACTIVE NEWSGROUPS +[S] . +L'annonce de la capacité est suivie de la liste des algorithmes gérés. On +trouve évidemment l'algorithme obligatoire DEFLATE mais aussi un algorithme +non-standard (imaginaire, ce n'est qu'un exemple) SHRINK. + +Le client peut alors utiliser la commande COMPRESS, suivie du nom d'un +algorithme (cette commande a été ajoutée au registre IANA des commandes NNTP[1] +). Voici un exemple où le serveur accepte la compression : + +[C] COMPRESS DEFLATE +[S] 206 Compression active +(À partir de là, le trafic est comprimé) +Attention à ne pas confondre la réponse du serveur à une demande de ses +capacités, et la commande envoyée par le client (dans les deux cas, ce sera une +ligne COMPRESS DEFLATE). + +Et voici un exemple où le serveur refuse, par exemple parce que la compression +a déjà été activée : + +[C] COMPRESS DEFLATE +[S] 502 Command unavailable + +Si on utilise TLS, ce qui est évidemment recommandé pour des raisons de +confidentialité et d'authentification, l'envoyeur doit d'abord comprimer, puis +(si SASL est activé) appliquer SASL (RFC 4422), puis seulement à la fin +chiffrer avec TLS. À la réception, c'est bien sûr le contraire, on déchiffre le +TLS, on analyse SASL, puis on décomprime. + +Voici un exemple d'un dialogue plus détaillé, avec TLS et compression : + +[C] CAPABILITIES +[S] 101 Capability list: +[S] VERSION 2 +[S] READER +[S] STARTTLS +[S] AUTHINFO +[S] COMPRESS DEFLATE +[S] LIST ACTIVE NEWSGROUPS +[S] . +[C] STARTTLS +[S] 382 Continue with TLS negotiation +(Négociation TLS) +(Désormais, tout est chiffré) +[C] CAPABILITIES +[S] 101 Capability list: +[S] VERSION 2 +[S] READER +[S] AUTHINFO USER +[S] COMPRESS DEFLATE +[S] LIST ACTIVE NEWSGROUPS +[S] . +[C] AUTHINFO USER michu +[S] 381 Enter passphrase +[C] AUTHINFO PASS monsieur +[S] 281 Authentication accepted +[C] CAPABILITIES +[S] 101 Capability list: +[S] VERSION 2 +[S] READER +[S] POST +[S] COMPRESS DEFLATE +[S] LIST ACTIVE NEWSGROUPS +[S] . +[C] COMPRESS DEFLATE +[S] 206 Compression active +(Désormais, toutes les données envoyées sont comprimées, puis chiffrées) +[C] CAPABILITIES +[S] 101 Capability list: +[S] VERSION 2 +[S] READER +[S] POST +[S] LIST ACTIVE NEWSGROUPS +[S] . +Et voici deux exemples où le serveur refuse la compression. D'abord parce qu'il +ne peut pas (manque de mémoire, par exemple) : + +[C] COMPRESS DEFLATE +[S] 403 Unable to activate compression +Et ici parce que le client essaie d'utiliser un algorithme que le serveur ne +connait pas : + +[C] COMPRESS SHRINK +[S] 503 Compression algorithm not supported +La liste des algorithmes standards (pour l'instant réduite à un seul) est dans +un registre IANA[2]. + +NNTP est un protocole dont les spécificités posent des problèmes amusants +lorsqu'on veut comprimer son trafic (section 3 du RFC). Les messages sont très +divers, ce qui peut être contrariant pour une compression fondée sur un +dictionnaire. Les réponses à certaines commandes (DATE, GROUP, NEXT, et le +CHECK du RFC 4644) sont peu comprimables. Par contre, les réponses à LIST, +LISTGROUP ou NEWNEWS sont facilement réduites à 25 à 40 % de la taille +originale avec zlib. + +En outre, les news envoyées sont dans des formats différents. Un article sera +parfois du texte seul, relativement court (et souvent uniquement en ASCII) et +se comprimera bien. Les textes plus longs sont souvent envoyés sous un format +déjà comprimé et, là, le compresseur NNTP va s'essouffler pour rien. Mais il y +a aussi souvent des données binaires (images, par exemple), encodées en Base64 +ou uuencode. On peut souvent les réduire à 75 % de l'original. (Deflate marche +bien sur des données en 8 bits mais l'encodage lui dissimule la nature +8-bitesque de ces données.) Si les données sont encodées en yEnc, elles seront +moins compressibles. + +Il y a apparemment au moins un logiciel serveur (INN) et un client (flnews[3]) +qui gèrent cette compression. + +Merci à Julien Élie pour sa relecture attentive (et pour avoir trouvé au moins +une grosse faute.) + +Liens: +[1]: https://www.iana.org/assignments/nntp-parameters/nntp-parameters.xml#nntp-parameters-1 (lien) +[2]: https://www.iana.org/assignments/nntp-compression-algorithms/nntp-compression-algorithms.xml (lien) +[3]: http://micha.freeshell.org/flnews/ (lien) -- cgit v1.2.1