Résumé

  • RFC 1281 qualifiait les règles de l’Internet de volontaires et largement inapplicables, sauf intervention du droit national. Le respect pouvait faire partie des conditions d’adhésion sans créer pour autant une police centrale.
  • Usagers, fournisseurs de services, opérateurs, vendeurs et développeurs conservaient des obligations distinctes. Chaque site devait rendre visibles sa politique, ses limites d’observation, son contact et son autorité de décision.
  • Détecter, notifier, répondre, identifier et sanctionner n’étaient pas une seule opération. Chaque passage demandait ses propres preuves et une habilitation identifiable.

La force fragile d’une coopération volontaire

Paru en novembre 1991, Guidelines for the Secure Operation of the Internet était un RFC informatif, non une norme Internet. Le réseau fonctionnait par collaboration : chaque réseau participant répondait de son exploitation, sans direction centrale au-dessus des différents composants.

RFC 1281 présentait ce volontariat comme une force et, peut-être, comme le trait le plus fragile de l’Internet. Les règles restaient largement inapplicables, hormis les domaines couverts par le droit national. Toutefois, rejoindre l’Internet relevait aussi d’un choix. Le respect des règles pouvait donc entrer dans les conditions de participation, et leur violation fournir des motifs de sanction.

Des motifs ne sont pas une décision. Le texte commun pouvait justifier l’examen d’une conséquence ; il ne désignait ni l’autorité compétente, ni le contrevenant, ni une peine uniforme. L’annexe renvoyait la sanction au site concerné et à la nature de l’incident. La norme partagée et le mandat local se répondaient sans se confondre.

La responsabilité gardait plusieurs propriétaires

La sécurité couvrait la confidentialité, mais aussi la vie privée, la modification non autorisée, le déni de service et l’accès indu. Les usagers devaient comprendre la politique, la respecter, répondre de leurs actes et employer les protections disponibles. Les fournisseurs de services devaient maintenir la sécurité et annoncer les politiques ainsi que leurs changements. Les vendeurs et développeurs devaient livrer des systèmes solides, expliquer les fonctions de sécurité, corriger les défauts et diffuser les remèdes à temps. Tous devaient coopérer, et l’amélioration devait rester continue.

Cette répartition empêchait un bureau de sécurité de devenir le propriétaire imaginaire de toutes les fautes. Une faiblesse technique n’autorisait pas l’intrusion. L’ouverture d’un site ne supprimait pas son devoir d’aider les autres. Le correctif du vendeur ne remplaçait ni la configuration de l’opérateur ni sa réponse à l’incident.

Avant toute attribution de responsabilité, il fallait donc retrouver l’obligation précise, son détenteur et les moyens dont celui-ci disposait. « Échec de sécurité » n’était pas une catégorie suffisante pour décider qui devait réparer.

Une politique devait atteindre ceux qu’elle obligeait

L’annexe de RFC 1281 demandait une politique claire, communiquée, conservée et accessible avec les conditions d’accès. L’existence d’un document ne prouvait pas que la règle s’appliquait à une personne donnée. Il fallait pouvoir retrouver la version, sa date d’effet, son public et la notification des changements.

Le RFC 1244, paru quelques mois plus tôt, détaillait ce chemin. Une politique ne devenait efficace qu’une fois communiquée aux usagers et aux responsables de maintenance. L’accès pouvait être subordonné à une déclaration signée attestant la lecture et la compréhension. Une annonce préalable et une période de commentaires pouvaient aussi laisser une trace.

Le texte, sa remise, l’accusé de compréhension et le périmètre d’application sont quatre faits différents. Une sanction exige en plus la preuve du comportement, une décision autorisée et une conséquence permise par la politique ou par le droit.

Observer imposait de tenir le registre de la vie privée

RFC 1281 recommandait journaux, audits et traçage pour suivre la conformité et les incidents. Dans le même mouvement, il imposait de publier ce qui était recueilli, par qui cela pouvait être consulté et dans quel but. La faculté de voir ne suffisait pas à rendre le regard légitime.

RFC 1244 distinguait en outre la collecte de diagnostic ordinaire d’une enquête sur une violation. Une même trace réseau change de nature lorsque sa finalité passe du dépannage à l’examen du comportement d’une personne. Un audit peut attester ce qui a été contrôlé et le résultat attendu ; il fournit une assurance, pas une preuve absolue.

Une observation exploitable doit donc conserver son but, sa durée de rétention, son périmètre, ses lecteurs, son intégrité et la question à laquelle elle peut répondre. Sans ce contexte, un pouvoir accordé pour maintenir un service peut s’étendre silencieusement au jugement des usagers.

Être joignable ne signifiait pas pouvoir décider

Chaque site devait publier un contact de sécurité connu. Mais ce contact devait soit être habilité à prendre une décision, soit pouvoir joindre rapidement la personne qui l’était. Le texte séparait expressément l’accueil du message de l’exercice du pouvoir.

Une adresse prouve qu’une alerte a une destination. Elle ne prouve pas que son titulaire peut isoler un système, divulguer des données, suspendre un accès ou saisir les forces de l’ordre. RFC 1244 recommandait précisément de déterminer à l’avance qui pouvait parler aux sites distants, à la presse ou aux autorités, et quelles informations pouvaient être communiquées.

Le RFC 2350 distinguera plus tard la communauté desservie par une équipe de réponse des systèmes qu’elle peut effectivement contrôler, tout en demandant d’annoncer son parrainage et son autorité. Ce formalisme de 1998 n’existait pas déjà sous cette forme en 1991. Il rend néanmoins visible la même erreur : une porte publique n’est pas un mandat universel.

L’alerte ne contenait pas déjà la peine

Lors d’une intrusion, RFC 1281 reconnaissait un arbitrage : fermer rapidement l’accès, ou maintenir brièvement une voie observable afin d’identifier l’auteur. Il fallait prévenir les autres sites touchés, sans imposer une divulgation illimitée susceptible d’aggraver le risque.

Détection, qualification de l’incident, repérage des victimes, notification, décision de confinement, investigation, attribution et sanction formaient ainsi une suite de décisions. Une alerte n’était pas encore un incident ; un incident n’était pas une identité ; une identité n’établissait pas l’intention ; l’intention ne fixait pas automatiquement une conséquence.

Le RFC 2196 formulera plus tard une politique comme un ensemble de règles réalisables, applicables par des contrôles et des sanctions, et claires sur les responsabilités. Pour sanctionner, il invitait à distinguer l’erreur, la naïveté et l’intention. Cette précision ultérieure confirme la valeur de la séparation, sans transformer RFC 1281 en code pénal rétrospectif.

Le mérite du texte de 1991 fut de ne pas promettre un levier unique pour tout l’Internet. Il demanda à chaque participant de rendre explicites la règle, sa notification, l’observation autorisée, le contact, le décideur et la preuve qui permettait de passer d’un acte au suivant.

Sources et limites

L’analyse repose d’abord sur le texte officiel du RFC 1281, complété par le contexte immédiat du RFC 1244. Ce dernier se disait incomplet et centré sur des ressources américaines : aucun des deux ne vaut loi universelle. Les RFC 2196 et RFC 2350 servent uniquement à montrer la formalisation ultérieure de la politique, de la sanction, de la communauté desservie et de l’autorité.