IETF116 直前なので「IETF ダンス」について振り返る: 2-architecture
— DNS, Security, trust — 7 min read
IETF ダンスとは
DANCE とは DANE Authentication for Network Clients Everywhere のことであり，現在 IETF で DANCE WG が組織されています．「IETF ダンス」なる踊りはありません．タイトル詐欺でごめんなさい．
一連のブログポストで DANCE について書いていきます．
第 1 回: https://blog.jj1lfc.dev/posts/dance-charter/
第 2 回: 本記事
draft-ietf-dance-architecture-01 を読む
本記事では DANCE の根本となる draft-ietf-dance-architecture-01 を読んでいきます．タイトルは「An Architecture for DNS-Bound Client and Sender Identities」となっています．原文はこちら をご参照ください．本記事はお気持ち翻訳であり，一部はしょっています．
本文書は執筆時点で Active Internet-Draft となっており，最終更新は 2023 年 1 月 23 日です．
Abstract
このアーキテクチャドキュメントでは，既存のモノのセキュリティと TLS おベースとするプロトコルをコンテキストとして，TLS クライアントのための DANE DNS レコードの使用と互いの identity の伝達に関する 用語，通信，認証パターンを定義します．
Introduction
ここからは大分はしょります．
チャーターの記事で述べたとおり，公開鍵ベースの識別・認証を行う上で現在一般的に使われている CA による PKI モデルには root of Trust を全て共有しなければならないという限界があります．例えば，組織の PKI を構成すればメールや LDAP と連携して組織内の物や人を管理するのは楽になりますが，これを対象組織の外でやろうとするととても大変です．このような制限が PKI の実装とメンテにおけるコストを高くします．
DANCE では DNS 名前空間を用いることで，PKI ベースの IoT デバイスの identity をユニバーサルに発見可能にし，より広く認識可能にし，かつメンテナンスコストをより低くすることを目的とします．
Conventions and Definitions
- “How to Dance with ENTITY”: DANCE が特定のプロトコルでどう使えるか，ということを「ENTITY とどう踊るか」と表現します．
- “DANCEr”: DANE をつ買うことになっているプロトコルを「踊り手」と表現します．
Communication Patterns
クライアント/サーバ
名前の通りで，安全とも割れる実装はクライアント-サーバ間で直接の TLS セッションを張ることです．もしくは，公開鍵ベースの相互認証です．
DANE を拡張しクライアント identity に対応することで，サーバはクライアント証明書を発行したプライベート PKI と独立してクライアントを認証することができ，これにより CA 証明書の管理の複雑さやクライアント identifier の衝突を防止することができます．
p2p
クライアント/サーバと同じです．メッシュネットワークや IoT，マルチメディアセッション (チャットやメッセージング) などで利用できます．
Decoupled
このアーキテクチャでは情報の生産者と消費者を直接は繋がらず，少なくとも 1 つのメッセージング指向ミドルウェアによって分離されます．このミドルウェアはサーバとして生産者・消費者に対して TLS セッションを張れます．これで，生産者・消費者がミドルウェアを信頼している限り，送信エージェントと受信エージェントは互いを信頼できます．
S/MIME のように，既存の store-and-forward プロコトルでは，証明書は署名されたメッセージ自体の中で伝送されることもあります．IoT アプリケーションではネットワークがより制約される可能性があり，このようなアプリケーションでは out-of-band の鍵発見メカニズムで必要なときだけ証明書を取得できるかも知れません．
Client Authentication
長いので Overview のみ．
クライア ントはサーバと TLS コネクションを張り，証明書の subjectAltName dNSName にクライアント名を表示します．また，DANE-client-id を使ってサーバに「証明書公開鍵のある DANE レコードの名前が dNSName にあるよ」と伝えます．サーバが DNSSEC 応答の検証に成功したら，サーバは証明書を検証しコネクションセットアップは完了です．
DNS で TLS 認証に必要な証明書情報をサーバに渡すため，まだ認証されていないクライアントがサーバに特定の DNS 検索を行わせることになります．これは DDOS の機会になり得ます．例えば，応答が遅く設定された権威 DNS サーバによって TLS 認証プロセスや上流リゾルバへのコネクションが同時に大量に飛ぶことになります．この類いの攻撃では TLS サーバのパフォーマンスや可用性に影響し得ます．
4.1.1-4.1.9 では様々なアプリケーションの例を示しています．
4.2-4.4 ではそれぞれオブジェクトセキュリティ，運用上の異常検知，近接エコシステムのコンポーネントについて述べられています．
Security Considerations
Confidentiality
DNS クライアントは認証先のアイデンティティ保護のため，信頼する DNS リゾルバとの通信に DNS over TLS を使うべきです．
Integrity
DNS 上の公開鍵の完全性は最も重要です．DNS スタブリゾルバは DNSSEC 検証すべきです．
Availabiity
DNS の可用性で重要な事は TTL を適切に利用することです．TTL を小さくすると観察者 視点でどのデバイスがアクティブかクエリの量から推察できます． DoT/DoH/DoQ などの暗号化トランスポートではクエリは見えにくくなりますが，リゾルバのログも情報源になります．
Privacy
証明書で証明される ID が直接的ないし間接的に個人と関連する際はプライバシへの考慮が必要です．この分野ではさらなる作業が必要です．
ちょっとこう煩雑になりましたが，このくらいでまとめておきます．書き終えて思ったのは，これはたぶん原文をちゃんと読んだ方が良いです．．．