要約

  • draft-ietf-dance-client-auth-14 では、TLS 1.3クライアントがTLSAレコードの完全な所有者名を送り、サーバーがその名前をDNSで問い合わせ、DNSSEC検証後に証明書または生公開鍵と照合する。
  • 照合成功は限定された名前と鍵の関係を示す。利用者や端末の割当て、サーバーの許可リスト、アプリケーション操作の権限、結果の発生は別々に立証しなければならない。

この仕組みで最初に動くのはサーバーである。CertificateRequestに空のdane_clientidを入れ、対応能力を示す。DANE認証を望むクライアントは、Certificateメッセージに証明書または生公開鍵と、TLSAレコードの完全な所有者名を返す。サーバーは名前を加工せず、そのままDNSへ問い合わせる。

DNSSEC検証済みのTLSA RRsetが得られ、少なくとも一件が提示された鍵材料に一致すれば、対向が対応する秘密鍵を持つことをTLS層で確認できる。これは有用である。だが、名前が誰を意味するか、端末が現在も同じ組織に所属するか、そのサービスへ入ってよいかは答えない。草案自身が、サーバー固有の許可リストと認可規則を残している。

審査中の仕様を完成品として扱わない

対象は2026年9月11日付の第14版である。DatatrackerではDANCE作業部会の有効なInternet-Draftで、想定RFCステータスはProposed Standard。IESGは9月15日に2回目のIETF Last Callを開始し、期限を9月29日とした。まだRFCでも承認済み方針でもない。

現時点の専門レビューは割れている。Security DirectorateはReadyとし、拡張違反時の参照と生公開鍵の結び付き説明を軽微な論点に挙げた。一方、DNS DirectorateはNot readyである。_serviceと_device形式がRFC 8552の下線付きノード名登録に適合しないこと、ClientNameの表示形式と255オクテットの説明を問題にしている。両方が現在の記録だ。

DNSSEC、TLSA、名前の意味

サーバー側DANEでは、通常ポートとトランスポートからTLSA所有者名を導く。クライアント名には普遍的な形式がないため、第14版は完全な名前をクライアントに送らせる。サービス別、デバイス別、自由形式の例はあるが、TLS層はその社会的意味を決めない。

DNSSECが認証するのは検証チェーン下のDNSデータである。ラベルが社員、装置、ワークロード、メール送信者のどれを指すかは命名主体の運用に依存する。署名の妥当性から、割当ての現在性までを推論してはいけない。

サーバーは設定済みtrust anchorまで自ら検証するか、安全な接続先の検証リゾルバーとAD bitを信頼する。署名なし、不安全な委任、検証失敗、NXDOMAIN、NODATAは認証済みTLSAセットにならない。失敗時に接続を切るか未認証として扱うかもサーバーポリシーである。

DANE-EE usage 3は証明書または鍵を直接照合するため、名前が証明書になくてもよい。DANE-TA 2とPKIX 0/1ではClientNameがdNSName SANに存在し、RFC 7671に従う照合も必要になる。生公開鍵ではRFC 7250の仕組みを使い、名前は拡張だけが運ぶ。どの枝でもアプリの権限は別である。

成功を一つの記録にまとめない

運用証跡は、受信ClientName、DNS応答とTTL、DNSSEC検証器、trust anchor、TLSAのusage・selector・matching type、証明書またはSPKI、名前の割当て、端末やアカウントの状態、許可リスト、アプリ認可、実行結果に分ける必要がある。

キャッシュされたTLSAが有効でも端末は再配属済みかもしれない。TLSハンドシェイクが成立してもテナント境界で拒否されることがある。操作が許可されても下流で失敗する。鍵の一致を最終結果まで拡張すると、どの管理者がどの判断をしたのかが消える。

また、TLS 1.3のCertificateは暗号化されるが、サーバーが続けて行うDNS問い合わせは暗号化DNSがなければ名前を露出し得る。RFC 9156のQNAME minimisationは上位層への露出を減らす。問い合わせの観測はプライバシー上の証拠だが、侵害や悪用の成立証拠ではない。