要約

  • RFC 9558 は GOST R 34.10-2012 に DNSSEC アルゴリズム 23、GOST R 34.11-2012 に DS ダイジェスト種別 5 を割り当て、鍵・署名・ダイジェストの厳密な形式を示す。
  • 文書は Independent Submission の Informational RFC であり、IETF 合意、暗号適性の独立評価、実装や普及の保証ではない。
  • 信頼できる結論には、登録、署名実装、権威側公開、親 DS、バリデータ対応、連鎖検証、リゾルバ状態、アプリ観測を分離した受領記録が要る。

正しい DS を見ても、処理できないリゾルバがある

障害訓練で、運用者は子ゾーンにアルゴリズム 23 の DNSKEY と RRSIG を置き、親にはダイジェスト種別 5 の DS を置いた。社内バリデータでは Secure になる。ところが別地域の利用者は、その組み合わせを実装していない再帰リゾルバを使っていた。

RFC 6840 の規則では、未知または未対応の鍵アルゴリズムやダイジェストを指す DS は検証経路の判定から外される。対応可能な DS が一つも残らなければ、子ゾーンは未署名と同様に扱われる。署名が偽だったのではない。署名を評価できる経路が、その実装にはなかった。

この差は管理上重要だ。IANA 登録は対象を共通の名前で呼べるようにする。実行コードの配備までは行わない。RFC 9558 は座標を加えたのであって、到達性を保証したのではない。

文書の出自を省略してはいけない

RFC 9558 は 2024 年 4 月、Independent Submission stream から Informational として公開された。Standards Track ではなく、IETF コミュニティの合意を表さない。RFC Editor も、実装または配備の価値について判断しない。

さらに本文は、GOST R 34.10-2012 と GOST R 34.11-2012 の暗号学的性質が独立検証されていないこと、IETF も IRTF も特定用途への適性を分析していないことを明記する。「RFC になった」を「IETF が推奨した」と読み替える余地はない。

それでも文書には明確な役割がある。採用を選ぶ当事者が、同じ鍵と署名を同じバイト列として交換できる。合意されているのは表現であり、受容ポリシーではない。

バイト順序は運用境界である

選択されたプロファイルは 256 ビット署名、256 ビットダイジェスト、パラメータセット A である。楕円曲線点 Q=(x,y) は DNSKEY 内で 64 オクテットとなり、x の 32 オクテット little-endian、続いて y の 32 オクテット little-endian で並ぶ。公開鍵と署名は各 512 ビット、ダイジェストは 256 ビットだ。

数学的に正しい点でも、バイト順序を誤れば相手は同じ点を復元できない。RFC は既存の GOST 対応 X.509 API に渡すため、30 バイト固定の ASN.1 SubjectPublicKeyInfo 接頭辞も示す。これは形式変換であって、証明書や信頼アンカーではない。

RRSIG は RFC 4034 の署名対象を GOST R 34.11-2012 でハッシュし、GOST R 34.10-2012 で署名する。例示の疑似乱数 k は再現用であり、実署名には使用禁止だ。テストベクトル一致と、本番の乱数管理は別の証拠である。

23 と 5 は別の接合部を記述する

IANA の DNSSEC レジストリでは ECC-GOST12 がアルゴリズム 23、DS レジストリでは GOST R 34.11-2012 が種別 5、状態 OPTIONAL である。23 は DNSKEY と RRSIG の解釈方法を示し、5 は親の DS が子の DNSKEY をどう要約するかを示す。

RRSIG が正しくても、親からの DS 接合がなければ認証された子にはならない。DS が一致しても、バリデータが両アルゴリズムを処理できなければ道はない。実装が対応しても、古いキャッシュや異なる信頼アンカーを観測すれば結果は変わる。

監査には DNSKEY・RRSIG・DS の各 RRset、親と子の観測地点、serial、署名期間、TTL、信頼アンカー、バリデータ版、対応アルゴリズム一覧が必要だ。「DNSSEC 有効」という一行では再現できない。

Insecure と Bogus を混ぜない

未対応のために経路が消え、未署名相当となる状態と、対応している経路の検証に失敗して Bogus となる状態は異なる。前者に再署名を繰り返しても、相手のソフトウェアには機能が増えない。後者を単なる互換性として扱えば、実際の破損を見逃す。

インシデント記録は、どのバリデータが、どのアルゴリズム集合で、どの時刻の RRset を、どの信頼アンカーから評価し、どのセキュリティ状態を返したかを残すべきだ。一つの dig 成功は市場全体の証明ではない。

二重 KSK は時間を買うが、状態も増やす

RFC 9558 は、GOST 対応 DNSSEC ソフトウェアが広がるまで、GOST 専用を意図する場合を除き、二つの KSK アルゴリズムで署名することを勧める。アルゴリズム 23 を知らないバリデータにも、もう一つの認証経路を残すためだ。

同時に、鍵、DS、RRSIG、有効期間、親側公開、キャッシュ、撤去順序が倍に近づく。RFC 6840 は有効な RRSIG が一つあれば受け入れ、すべて失敗した場合だけ Bogus とする方針を示すが、ローカルポリシーやキャッシュ時刻の差は残る。

旧経路を消す前に、複数ネットワークから新経路の構築を確認し、親 DS と子ゾーン、TTL、署名期間を追跡する必要がある。二本が見えたという観測は、一本を消してよいという承認ではない。

検証後にもアプリケーション境界がある

Secure は、設定済み信頼アンカーに対して RRset が DNSSEC 規則上認証されたことを示す。サービスの稼働、組織の法的身元、すべての用途における暗号適性、その後の接続成功までは示さない。

DO は DNSSEC データを要求し、CD は検査動作を変え、AD は条件付きで認証状態を伝える。stub と再帰リゾルバの経路が信頼できない場合、あるいはアプリが状態を利用しない場合、そのビットはエンドツーエンドの根拠にならない。

最後に必要なのは、信頼したリゾルバ、通信路、返された状態、適用ポリシー、実行した判断、観測した結果である。登録票はこの最後の責任を引き受けない。

情報源

出典