要約

  • 9月25日付のPIM作業部会のInternet-Draft第25版は、第5節を「Illustrative GAAP API」とし、GAAPはライブラリーでもPython APIでもなくプロトコルだと明記した。疑似Pythonの呼び出しは一例で、ワイヤ上のClaimに従えば別の窓口でも窓口なしでもよい。ただし第24版もすでに例示を非規範的と呼んでいた。
  • Claimの記録にはIPv4・IPv6のグループアドレス、時刻、グループ名という四項目だけが含まれると整理し、認証のないChaCha20が改ざんされ得る理由も追記した。新しいパケット形式や新たな禁止事項、実際の攻撃事例を示したわけではない。

アドレスを取得するプログラムがどの関数を呼ぶかは、そのプログラムを作る組織が決められる。一方、別の参加者へ送るClaimの意味は、片側だけの判断で変えられない。単一の割当サーバーに依存せずマルチキャストグループアドレスを扱うGAAPでは、この差が重要になる。草案第25版は第5節の見出しを改め、疑似Pythonを読者のための説明に位置付け、実装の必須インターフェースではないことをはっきり書いた。

「Pythonの必須APIを廃止した」という説明は正確ではない。前版でもAPIは例示的で非規範的だった。今回の追加は、例の関数名やライブラリー構造をプロトコルと取り違える余地を狭めた点にある。アプリケーションが常駐プロセスと通信する方式を選んでも、機器内に機能を組み込んでも、草案が求める共通面はワイヤ上のClaimだ。ここで挙げた実装方式は考え得る選択肢であって、GAAPの導入例を確認したという意味ではない。

第4節でも同じ「説明と形式」の区別が加わった。Claimのレコードを構成するのは、IPv4マルチキャストグループアドレス、IPv6マルチキャストグループアドレス、タイムスタンプ、グループ名の四つ。その後に続く使い方、比較方法、解析方法の記述は追加フィールドではない。したがって第24版と第25版を比較して、五番目の項目が新設されたとか、順序が変わったとか、ネットワークに移行作業が必要になったと読むことはできない。変わったのは仕様文の境界の示し方である。

安全性の説明にはもう一つの誤読を防ぐ加筆がある。ChaCha20をメッセージ認証コードなしで単独使用してはいけないという要件は第24版から存在した。第25版は、完全性がなければストリーム暗号の暗号文は可変で、経路上の攻撃者がビットを変えることで受信側の復号後のグループアドレス、時刻、名称を気づかれずに変え得ると説明した。保護されていると思い込ませる方が、暗号化していない基本モードだと明示する場合より危険になり得る、というのが草案の評価だ。現実の侵害や脆弱なGAAP配備が報告されたわけではない。

この版から読み取れる統治上の論点は、共有規約を狭くすることと、共有規約を弱くすることは違う、という点だ。各実装のプログラミング窓口は自由でも、相手が解釈するClaimの四項目や、暗号化を選ぶときの完全性は自由記述ではない。指定のPythonメソッドを備えているかだけを検査しても相互運用性は分からないし、通信が暗号文であるだけでは改ざん検知を証明できない。これは本文の分析であってIETFの認証制度ではない。

Datatracker上の第25版はPIM作業部会のInternet-Draftで、IESG EvaluationのAD Followup段階にあり、目標はExperimentalだ。RFCにはなっていない。BTWが先に報じたGAAP第23版の記事は固定された割当範囲と、ネットワーク分断が解けた後の同名Claimの収束を扱った。今回の修正はその問題の解決を示すものではなく、別の主題である規約、例、完全性の境界を明確にする。

出典