要約
- RFC 9761 は、IoT 機器が通常使う TLS/DTLS パラメータを MUD で宣言できるようにする。宣言は比較基準であり、端末が健全だという証明ではない。
- プロファイル外でも既知の値なら処置の根拠になり得る。ファイアウォール自身が知らない値は、未知であることだけを理由に遮断してはならない。
- TLS 1.3、ECH、暗号化 DNS は受動観測を狭める。プロキシは情報を増やす一方、プライバシーと証明書検証の境界を作り替える。
止めなかった通信こそ、監査で説明が必要だった。ClientHello に古い検査装置が解釈できない値が含まれていたからだ。プロファイルにも載っていない。それでも遮断しなかった。
これは例外処理ではなく、RFC 9761 の中心的な非対称性である。プロファイルにない値をファイアウォールが知っていれば、想定外の TLS 利用として警告、隔離、遮断を検討できる。値そのものをファイアウォールが知らなければ、無知だけを理由に止めるのが誤りとなる。将来の正規拡張まで古い検査辞書に従属させないためだ。
想定を述べる者と決める者
RFC 8520 の MUD は、用途が限られた機器の通信を製造者が記述し、ローカルな管理者がアクセス制御へ落とし込む仕組みである。製造者は想定を述べる。ネットワーク運用者は現場の条件を加え、許可や拒否の責任を負う。
RFC 9761 は RFC 8519 の ACL に TLS/DTLS の輪郭を加える。版、暗号スイート、拡張、対応グループ、署名方式、PSK 交換モード、ALPN、信頼アンカー、受理する認証局、証明書圧縮方式を記述できる。単なる宛先ポートよりも、はるかに限定された比較が可能になる。
ただし、精密な記述は内部状態の観測ではない。MUD ファイルは想定を示し、パケットは一回の提示内容を示し、ファイアウォールは自分の理解範囲を示す。三つが一致しても、動作中のコードを証明したことにはならない。
四つの組合せを別々に記録する
値がプロファイル内で、検査側も既知なら、期待集合との一致である。マルウェアも同じスイートや拡張を模倣できるため、健全性の保証にはならない。
値がプロファイル外で、検査側には既知なら、意味のある差分になる。未許可ソフトウェア、侵害、公開前の正規更新、誤った機種紐付けのいずれもあり得る。ローカル方針で止める場合は、値と版と判断者を保存する。
プロファイル内なのに検査側が未知なら、遅れているのは制御装置である。値を無視して残りの方針を適用し、ファイアウォール供給者と機器所有者へ警告する。両方で未知の場合も、その未知だけでは止めない。TLS 1.3 が中間装置に求める未知スイート・拡張の無視と同じ原則である。
GREASE は未知値を通せるか試している
RFC 8701 の GREASE は、予約値を意図的に提示し、将来の拡張を壊す実装を早く見つける。RFC 9761 は GREASE 値を MUD プロファイルへ入れることを禁じる。固定プロファイルとの差分だけで敵視すれば、ファイアウォール自身が TLS を硬直化させる。
IANA の TLS パラメータ、YANG パラメータ、MUD の各記録は共通語彙を保つ。登録済みであることと、現場の解析器が対応済みであることは別だ。判断記録には、レジストリ時点、プロファイル改訂、実際にロードされたモジュール版が要る。
未知を一律拒否する設計では、更新の遅い中間装置の供給者が新しい TLS 値の利用時期を事実上決める。許可しつつ警告する経路は、既知の危険に対するローカル権限を弱めない。知識不足に無制限の拒否権を与えないだけである。
TLS 1.3 では見えていた証明書が消える
TLS/DTLS 1.2 では ClientHello、ServerHello、Certificate が平文だった。TLS 1.3 は ClientHello 以外の多くを暗号化し、DTLS 1.3 も同様に可視性を狭める。受動ファイアウォールは提示版や一部の候補を見られても、サーバー証明書まで検査したとは言えない。
ECH は SNI などを隠し、暗号化 DNS は名前解決を隠す。機器がネットワーク指定外のリゾルバを使えば、ドメイン名ベースの MUD 制御は適用点を失う。DDR と DNR はネットワーク指定の暗号化リゾルバを知らせられるが、端末が従った事実は別に確認する必要がある。
完全な TLS 1.3 観測にはプロキシが必要になる。RFC 9761 は対象を企業が所有・管理する IoT 機器に限定し、組織のセキュリティとプライバシー要件を課し、可能ならプロキシを使わないよう勧める。復号地点は新しい信頼端点であり、証明書検証の場所を変え、個人情報や医療情報を扱い得る。
RFC 9325 は弱い TLS/DTLS 選択を評価する基準を与える。OSCORE は、別層に中間装置がいてもアプリケーションオブジェクトを端末間で保護する構成を示す。どちらも特定の現場で代理復号を正当化するものではない。
一致しても、別のプログラムかもしれない
RFC は、悪意あるエージェントが正規プロファイルを真似できると認める。機種ごとの差、認証局、宛先、更新頻度が模倣を難しくしても、不可能にはしない。一致は一種類の異常がなかったという結果にすぎない。
必要な証拠は、機器・機種の紐付け、MUD URL、ファイルハッシュと署名、プロファイル版、ファームウェア、フロー、パラメータの生値、プロファイル照合、解析器版、DNS/IP 文脈、ECH、プロキシ、ローカル処置、端末調査、アプリケーション結果である。is-supported が偽なら製造者の更新約束が終わったことを示すが、機器が現在故障している証明ではない。
現実の層を分ければ、標準、登録、署名文書、実行規則、パケット、業務結果を混同しない。動作するコードの優位は、ロード中の版を確認する原則になる。最小の初期仕様と将来判断の局所化は共通語彙を作っても、各遮断の権限まで中央へ渡さない。
RFC 9761 が増やすべきものは、ファイアウォールの威信ではない。誰の知識が足りないのかを区別できる記録である。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
