Path: ...!news.mixmin.net!aioe.org!Zx7D/NYItFLykhxJSZ3Jrw.user.46.165.242.91.POSTED!not-for-mail
From: Franck <franck@email.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: Re: usage de cancel-clock
Date: Sat, 10 Sep 2022 07:47:56 +0200
Organization: Aioe.org NNTP Server
Message-ID: <tfh8ec$r4p$1@gioia.aioe.org>
References: <tfers7$g3o$1@ns507557.dodin.fr.nf>
 <tfesf2$1su$1@rasp.pasdenom.info> <tfetfs$ge4$1@ns507557.dodin.fr.nf>
 <tfeu69$3bm$1@shakotay.alphanet.ch> <tfeul8$6r0$1@rasp.pasdenom.info>
 <tfevb3$8ld$1@shakotay.alphanet.ch> <tff0h5$dom$2@shakotay.alphanet.ch>
 <tff3e3$sg1$1@shakotay.alphanet.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="27801"; posting-host="Zx7D/NYItFLykhxJSZ3Jrw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.2
Content-Language: fr
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 3600
Lines: 61

Le 09/09/2022 à 12:10, M.V. a écrit :

> MID, STP ?

Message-ID

>> Tous les serveurs doivent faire de même pour la génération et la vérif
> 
> Quand tu dis « doivent » tu veux dire « ils ont l'obligation » ou bien
> « je suppose que » ?

La RFC "préconise" ces éléments, après rien n'empêche d'utiliser un 
autre moyen qui permette d'identifier le message et son auteur.

Donc MID et UID en sont le reflet.

Mais si tu veux en plus ajouter l'entête "Date:" dans le calcul du CK, 
rien ne l'empêche!

Au lieu de K = HMAC(sec, uid+mid), cela peut être  : K = HMAC(sec, 
uid+mid+date).

De toutes façons le CL restera le Hash du CK généré, donc n'importe quel 
serveur pourra hasher le CK pour vérifier le CL.

En revanche, pour les serveurs qui autorisent les posts anonymes, 
l'utilisation de l'adresse IP n'est pas sûre mais peut être un début de 
solution (pour identifier l'auteur de l'article). En effet, il faut 
prendre en compte le fait qu'elle peut être mutualisée (VPN par exemple) 
ou ne pas être statique.

C'est d'ailleurs pour cette raison que les serveurs qui utilisent cette 
solution ne proposent les "Cancels/superseedes" que durant 24 heures 
après la publication de l'article.

L'IP n'est pas un élément permettant d'identifier un utilisateur de 
manière formelle entre deux dates (puisque entre la publication et 
l'annulation, cet élément peut changer).

Que ce soit avec une identification formelle (type UID) ou avec autre 
chose (IP par exemple), cet élément sera VÉRIFIÉ par le serveur et devra 
être identique entre l'article cancel et celui qui en est la cible.

Plus généralement, il est recommandé de ne pas utiliser un UID qui peut 
être modifié dans le temps (Par exemple l'entête "From:"). Le login 
envoyé avec la commande AUTHINFO reste le meilleur moyen d'identifier 
formellement l'utilisateur puisqu'il ne change jamais.

> Je ne vois en réalité pas pourquoi tous les serveurs devraient faire la
> même chose pour *générer* CK mais pour le re-calcul du CL à partir du CK
> joint à un message, là oui.

Tous les serveurs ne sont pas "obligés" de le faire, la RFC indique 
simplement un moyen d'authentifier de manière unique un article et son 
auteur et ces deux informations sont les plus pertinentes.

Après, cela reste de la tambouille interne et effectivement le seul 
impératif reste la formule de génération du CL.

Franck