要約

  • 9 月 11 日に提出された draft-ietf-dance-client-auth-14 は、作業部会最終レビューと文書担当者のフォロー中にある Internet-Draft で、RFC や承認済み標準ではない。
  • 第 14 版は、DNSSEC 検証済み TLSA RRset 以外を、検証失敗、未認証応答、NXDOMAIN、NODATA の四種類として明記した。いずれも切断、または方針が許す場合の未認証扱いへ進む。
  • 結果分類、信頼経路、方針版、後段の認可を結ぶ小さな検索判断記録が要る。これは運用上の編集提案であり、IETF の要件ではない。

戻った手続き、進んだ文章

Datatracker によれば、「TLS Client Authentication via DANE TLSA records」の第 14 版は 2026 年 9 月 11 日付である。Security Area の DANCE 作業部会文書で、目標は Proposed Standard。しかし現在の表示は In WG Last Call で、document shepherd のフォローが続く。IESG の状態も Waiting for AD Go-Ahead::AD Followup だ。到達点ではなく現在地を示す情報である。

履歴を見ると、第 13 版は 7 月 23 日に提出された。7 月 28 日には作業部会状態が Submitted to IESG for Publication から In WG Last Call に戻った。第 14 版が受理されたのは 9 月 11 日である。新しい版番号を承認通知として読むことはできない。

ただし文章には明確な更新がある。第 13 版は DNSSEC 検証に失敗した場合だけを書いていた。第 14 版は条件を「DNSSEC 検証済み TLSA レコード集合以外の結果」に広げ、四種類を列挙した。

その後の処理は共通である。サーバーは TLS の handshake_failure で接続を中断するか、サーバー方針が認めるならクライアントを未認証として扱う。入力の語彙は増えたが、リスク判断は標準文書から現場へ残された。

逆向き DANE の問い合わせ

RFC 6698 と RFC 7671 の DANE は、クライアントがサーバー側の TLSA を引き、証明書や公開鍵を評価する使い方で知られる。DANCE 案は DNS による認証をクライアント側へ向ける。

対応サーバーは CertificateRequest で提案中の dane_clientid 拡張を提示する。DANE 認証を望むクライアントは Certificate メッセージに、自身の TLSA レコードの完全な所有者名を入れる。サーバーはポートやトランスポートから別名を作らず、その文字列をそのまま問い合わせる。TLS 1.3 または DTLS 1.3 以降が前提だ。

DNSSEC の検証は、サーバー自身が設定済みトラストアンカー、通常はルートまで行える。もう一つは、安全な接続先の検証リゾルバーを信頼し、AD ビットを必須とする方法である。結論が同じでも、誰の検証結果を採用したかは異なる。

調査時点の IANA TLS ExtensionType レジストリには、dane_clientid の割当値が見当たらない。案も将来の割当として書く。番号、実装数、導入範囲を先回りして主張できる段階ではない。

四分類を一つの「失敗」にしない

DNSSEC 検証失敗は、適用した信頼連鎖と規則でデータを認証できなかった観測である。攻撃の確定でも、設定者の断罪でもない。

未認証応答は、未署名ゾーンまたは TLSA 名までの insecure delegation によって生じる。署名されたデータが検証で崩れた状態とは違う。RFC 4033が署名ゾーン、未署名ゾーン、トラストアンカーから生じる期待を分けるのは、この差を守るためでもある。

NXDOMAIN なら問い合わせた名前自体が存在しない。NODATA なら名前は存在し得るが TLSA 型がない。RFC 2308に沿うこの区別は、端末登録の削除と TLSA 配備漏れを別々に調べる手掛かりになる。

古い名前を送ったクライアント、意図的に未署名の領域、未完了の配備、壊れた検証経路など、原因候補は複数ある。案はそれらを悪意と決め付けない。

ところがログに handshake_failure しか残らなければ、四つの観測は一つになる。未認証のまま接続できた場合も、単なる「成功」と書けば同じである。プロトコルの局所的な選択自由と、説明可能性の欠如は別問題だ。

認証の後にも権限判定がある

検証済み TLSA RRset が返っても処理は終わらない。証明書用途、セレクター、照合方式に従い、提示されたクライアント証明書または raw public key と照合する。照合できなければ、案は再び切断か未認証扱いかをサーバー方針に委ねる。

照合成功は DANE の意味での認証であって、アプリケーション権限の付与ではない。サーバーは許可リストや受け入れるドメインなどを別途適用できる。認証済みでも権限がない場合があり、未認証で継続しても公開範囲だけに制限され得る。

DNS 結果、DANE 照合、アプリケーション認可は別々の三段階である。一つの成功フラグにすると、どの主体の規則が決定したのか分からなくなる。

最小限の検索判断記録

TLS の中に内部調査資料を詰め込む必要はない。クライアント名は人、機器、職務を識別し得るため、本文のセキュリティ考慮も相関リスクを挙げている。必要なのはアクセス制限された検索判断記録である。これは Daniel Kade の編集提案で、IETF、DANCE、IANA の要求ではない。

記録項目は、時刻、クライアントが示した TLSA 所有者名の許可済み表現または保護ハッシュ、問い合わせ型、四分類のどれか、DNSSEC 状態、ローカル検証か保護されたリゾルバーか、トラストアンカーや解決方針の参照、サーバー方針の版、選ばれた分岐でよい。後段へ進んだ場合だけ、証明書照合と最終認可も別欄に残す。

前段で止まった項目は「未到達」とする。NXDOMAIN から証明書不一致を推測せず、insecure を bogus と書き換えない。保持期間と閲覧者は識別子の感度に合わせる。公開時は分類別件数や方針変更だけを集計し、端末名や接続履歴は出さない。

Heng Lu の Policy Mirrorに照らすと、DNS 運用者、名前を示すクライアント、検証方法と TLS 方針を選ぶサーバー、権限を決めるアプリケーションを分けて見られる。Minimum Initial Specificationの考え方は、共有仕様を必要最小限にし、将来の局所判断を閉じない。第 14 版の二択はその余地を残す。記録は余地を奪わず、選択理由だけを失わせない。

情報源

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. 文書履歴
  3. 第 13 版
  4. 第 14 版
  5. DANCE 作業部会
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — DANE 運用
  8. RFC 2308 — DNS ネガティブキャッシュ
  9. RFC 4033 — DNSSEC の導入と要件
  10. IANA TLS ExtensionType レジストリ
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification