要約

  • TLSA RRset が DANE の証拠になるかは DNSSEC 検証結果で決まる。insecure または indeterminate は利用不能で、bogus は失敗を要求する。
  • 証明書用途、selector、matching type が、比較対象と証明書処理の規則を決める。
  • 安全に公開された関連付けでも、利用不能な場合や、サーバーが実際に提示する証明書または鍵と一致しない場合がある。
  • 運用記録では、公開済み、安全、利用可能、一致、受入れ済みを別の状態として扱う必要がある。

午前零時にサービス証明書が正常に更新されたとする。全サーバーは新しいチェーンを提示しているが、一部のクライアントのキャッシュには古い公開鍵を指す TLSA 関連付けが残る。DNS には TLSA があり、HTTPS 監視も正常なので変更票は閉じられた。それでもクライアントは、認証済みの関連付けと提示された鍵が一致しないため接続を中止する。

これは特定事業者の事故ではなく、仮想的な変更記録である。関連付けの公開と、証明書受入れに必要な全入力の整合は同じではない。

公開は最初の状態にすぎない

RFC 6698 の TLSA は、証明書用途、selector、matching type、証明書関連データからなる。前三者は、公開 CA の経路を制約するのか、信頼アンカーを示すのか、ドメイン発行の終端証明書を指定するのか、完全な証明書と SubjectPublicKeyInfo のどちらを比較するのか、完全一致・SHA-256・SHA-512 のどれを使うのかを決める。

問い合わせ名も、サービスポート、トランスポート、TLSA base domain から導かれる。別サービスの名前を調べたり、安全でない alias で止まったりすれば、形式上正しい DNS データを誤った判断に使うことになる。RFC 7671 は、安全に検証された CNAME 展開も base domain の選択に含める。RDATA だけの台帳では、関連付けが対象としたサービス識別子を失う。

DNSSEC が関連付けの利用可否を決める

RFC 6698 は DNSSEC 検証状態を前提にする。secure な TLSA RRset は、個別関連付けを禁止するローカル方針がない限り利用する。bogus 応答なら TLS を開始せず、進行中なら中止する。insecure または indeterminate な RRset は TLSA 認証に利用できない。

したがって「DNS にある」は「secure と検証済み」より弱く、secure でもまだ usable とは限らない。未知の用途、selector、matching type、壊れた比較データ、クライアント方針上弱すぎるアルゴリズムは関連付けを利用不能にする。

利用可能な関連付けが一つもなければ、アプリケーションは TLSA の入力なしで通常の TLS 処理を行う。一つ以上あれば、用途に応じた比較を実行し、成功する一致を見つけなければならない。対応機能や方針が違うクライアントは、同じ公開 RRset から異なる処理結果を得られる。

提示された証明書が規則を満たす必要がある

用途によって一致の意味は変わる。一部は PKIX 経路検証を維持し、DANE 用途は DNSSEC に基づく信頼アンカーや終端エンティティの直接関連付けを可能にする。selector は、同じ鍵を保つ証明書更新が一致し続けるか、証明書全体の同一性が必要かを左右する。

RFC 7671 は運用条件を加える。DANE-TA では十分なチェーン材料と、所定の場合には信頼アンカー証明書をサーバーが送る必要がある。SPKI selector の DANE-EE は同じ鍵なら更新後も一致できるが、別の鍵を提示すれば失敗する。digest agility は、壊れた関連付けや未対応のものを除外した後に適用する。

一般的な PKIX クライアントが成功しても、DANE クライアントが正しく拒否することがある。opportunistic なアプリケーションは利用可能な secure 関連付けがなければ未認証 TLS を選ぶ場合があるが、認証必須なら接続できない。受入れは DNS 行の属性ではなく、プロトコル証拠に対するアプリケーションの判断である。

時刻も公開と受入れを分ける

TLSA TTL、RRSIG の有効期間、リゾルバーのキャッシュ年齢、証明書展開順序が観測を制限する。RFC 7671 は、予定外の証明書またはチェーン変更後に古い TLSA をキャッシュしたクライアントが失敗し得ると警告する。長い署名期間は、署名済み旧データを再利用できる時間も延ばす。

更新計画は、新旧の関連付け、権威 DNS、セカンダリ、検証リゾルバーのキャッシュ、サービス展開、ロールバックを一体で扱う。一台の権威サーバーで新レコードが見えるだけでは、実際のクライアントが同じ結合を見ている証拠にならない。