要約

  • RFC 1459 の接頭辞は IRC 上の送信元を示したが、受信サーバーはその名前を内部状態から引き、到着リンクの先に登録された送信元かを照合した。
  • ニックネームの一意性、クライアント登録、リンク整合、メッセージ受理は別々の事実であり、どれも文章を書いた人間の本人証明ではない。
  • 不整合は黙って破棄されたため、後の説明にはメッセージ本文だけでなく、当時の接続、登録、時刻、処置の記録が必要だった。

コロンの後ろに証明はなかった

1993 年 5 月に実験的プロトコルとして公開された RFC 1459 は、BBS のチャットから成長した IRC を、クライアントとサーバーの世界規模ネットワークとして記述した。プロトコルの表面はテキスト行である。任意の接頭辞、コマンド、最大十五のパラメーターが並び、CR-LF で終わる。

接頭辞にはサーバー名、またはニックネームを置けた。ユーザー名とホストを伴う形もあった。接頭辞がなければ、受信した接続そのものが送信元とみなされた。接頭辞があれば、仕様はそれをメッセージの origin と呼んだ。

しかし、クライアントが任意の名前を書くことは許されない。書くなら自分の登録済みニックネームだけである。サーバーは名前を内部データベースで解決し、その送信元がメッセージの来たリンクの先に登録されているかを照合した。名前が存在しない場合、または別リンクの先にある場合、メッセージは黙って無視された。

ここでは三つの事実が接続される。行の文字列は主張、データベース行は既知のプロトコル主体、リンク対応はその主体の到来可能な関係である。構文が正しくても関係が誤っていれば、転送対象にはならない。

プロトコル上の出所は人間の署名ではない

リンク照合は狭いが重要な保証を与える。あるローカル接続が他人の登録名を接頭辞に書くだけで、その位置を奪うことはできない。隣接サーバーも、別の枝に属する既知の送信元を自由に投射できない。

一方で、照合対象は IRC の状態である。キーボードを操作した人物ではない。サーバーはニックネームのほかにユーザー名、ホスト、所属サーバーを保持した。接続時には DNS の正引き・逆引き、任意のパスワード、Ident 照会を利用できた。RFC 1459 自身、パスワードなしに接続の向こう側を確実に知るのは容易でないと認めている。

サーバー間パスワードが正しくても、それは各メッセージへの暗号署名ではない。ホストが誰に操作されたか、表示名が現実の誰に属するか、文章が途中で漏れなかったか、相手が実際に読んだかは、別の証拠を要する。

一意なニックネームは現在状態の成果だった

当時のニックネームは最大九文字で、ネットワーク内で一意であることが求められた。サーバーがクライアントを探し、応答を返すためである。一意性は永続的な所有権ではない。

同じ名前が別のクライアントとして到着すると、ニックネーム衝突になった。サーバーは人間の正当性を裁定せず、両方のインスタンスを消し、KILL を伝播して曖昧さを取り除いた。直接接続の新規要求なら、その要求だけを拒否できた。

WHOWAS は最近の利用履歴を返したが、それも運用上の過去記録である。KILL、MODE、KICK と改名が競合すると誤ったクライアントに作用し得るため、サーバーは改名履歴も追跡した。履歴は確率を下げても、仕様が認めた取り違えをゼロにはしなかった。

従って名前の意味には時刻が要る。いつ、どのセッションに、どのサーバーが割り当てたかを失えば、同じ綴りが一人の連続した人格に見えてしまう。

分断は照合対象の世界を二つにした

IRC サーバーは木構造を作り、それぞれが必要なネットワーク状態を保持した。中央サービスへの逐次問い合わせが不要な代わりに、ローカル複製が判断の根拠になった。

リンクが切れると、両側は異なるメンバー、チャンネル、ニックネームの集合を持ち得る。再接続時には互いが正しいと考える状態を交換する。分断中に同じ名前が両側で生まれても、どちらか一方の悪意を直ちに意味しない。

パケット記録だけでは、あるメッセージが消えた理由を説明できない。到着時刻、接続識別子、対向サーバー、当時の送信元レコード、期待リンク、実リンク、実行結果が必要である。後日同期済みのデータベースを見ても、過去の不一致は復元できない。

接頭辞は値であり、登録先は関係であり、破棄は決定である。転送、クライアント受信、画面表示、人間の理解はさらに後の出来事になる。

2000 年の文書群はリンク処置を明示した

RFC 2810 は IRC アーキテクチャを分離し、各サーバーがグローバル状態のコピーを持つことを、規模を制限する大きな問題とした。状態複製の負担は、送信元照合の負担でもあった。

RFC 2812 はクライアント側の接頭辞規則を保持した。接頭辞がなければ接続を出所とし、クライアントが付けるなら登録済みニックネームだけである。RFC 2813 はサーバー側を厳格にした。不明な接頭辞は破棄し、不明なサーバーを名乗る場合はリンク切断も必要になり得た。既知の送信元が別リンクに登録されていれば、常にメッセージを捨て、条件に応じてクライアントの KILL や接続切断を行った。

整合性を守る措置が可用性を失わせる場合がここにある。一つの矛盾からリンク全体を切れば、その枝の正当な利用者も同時に消える。安全上の判断とサービス結果は同じ記録ではない。

また、サーバートークンは一つのピア接続内でだけ一意で、グローバルではなかった。識別子は、それを発行した範囲と関係を離れると同じ証拠価値を持たない。

誤った 16 進値と正しく動いた区切り

RFC 1459 はコロンの値を 0x3B と誤記した。0x3B はセミコロンであり、検証済み Errata 4091 は 0x3A に訂正した。本文の文字と文法は、意図された区切りを示していた。

原仕様、維持された訂正、実装の三者は別の証人である。原仕様だけなら誤値を繰り返す。実装だけなら公開文書の誤りと訂正時期を失う。動くコードが一次的でも、歴史には変更記録が要る。

暗号化は別の境界を守る

後の RFC 2813 は PASS と OPER が平文で流れる点を挙げ、TLS のようなストリーム暗号を提案した。RFC 7194 はさらに IRC over TLS/SSL の既定ポートを登録した。

TLS は対象リンク上の資格情報や内容を保護し、ピア認証を強められる。しかし、ローカル状態と矛盾する接頭辞まで正しくするわけではない。暗号化されたピアが古い登録を送り得るし、正しいリンク照合が暗号化の実施を示すわけでもない。ポート登録は運用実績ではない。

RFC 1459 が残した境界は明快である。接頭辞は誰を名乗るかを示す。サーバーはどの関係から来たかを確認する。それでも、人間の本人性と最終受信は未証明のまま残る。