要約

  • TLSA レコードの所有者名には、ポート、トランスポート、基底ドメインが含まれる。一致が証明するのは、そのサービス組と検証方式における証明書関連であり、ホスト全体への信頼ではない。
  • 再検証可能な記録には、TLSA 問い合わせ名、DNSSEC 状態、certificate usage、selector、matching type、提示された材料、アプリケーション規則、観測時刻が必要である。「DANE 成功」だけでは境界が消える。

同じ鍵を別ポートへ持ち込む

検証用の構成を考える。service.example は TCP 443 と 8443 で同じ証明書を提示する。署名済みゾーンにある利用可能な TLSA RRset は _443._tcp.service.example のみである。443 のクライアントは DNSSEC を検証し、指定された証明書材料を照合できる。8443 のクライアントは _8443._tcp.service.example を問い合わせなければならず、前者の成功を借りられない。

これは製品障害の主張ではなく、権限の越境を検出する合成試験である。「このホスト上で同じ証明書が既に DANE を通った」という説明は直感的だが、RFC 6698 の主張ではない。ポートとトランスポートを DNS 名に埋め込むことで、一台のホスト上でもサービスごとに異なる関連、所有者、更新日程を持てる。

証明書指紋とホスト名だけを保存するシステムは、成功を成立させたサービス境界を捨てる。後から同じ指紋を見つけても、どの問い合わせが根拠だったかは復元できない。

問い合わせ名の導出過程を残す

TCP 上の直接 TLS では、典型的な形は _ポート._tcp.基底ドメイン である。ポートは十進数で表され、トランスポートラベルは別方式と区別する。基底ドメインはアプリケーション仕様が決めるもので、ログ作成者が接続後に都合よく選ぶものではない。

CNAME は問い合わせ先を展開し、SRV を使うアプリケーションは RFC 7673 に従ってサービス発見から基底名を導く。SMTP DANE では MX 発見、参照識別子、DNS エラー、フォールバックが RFC 7672 で個別に定義される。ソケットに残った最終 IP アドレスだけでは、権威ある TLSA 名を説明できない。

証拠には、元のアプリケーション宛先、MX/SRV/CNAME の各段階、展開前後の名前、ポート、トランスポート、最終 TLSA 名、DNSSEC 結果、導出に用いた規則を保存する必要がある。

usage は信頼方式を選ぶ

PKIX-TA(0) は通常の PKIX パス検証を維持しつつ CA を制約する。PKIX-EE(1) は終端証明書を制約し、同じく有効な PKIX パスを必要とする。DANE-TA(2) は DNSSEC を通じてトラストアンカーを表明し、DANE-EE(3) はサービスを終端証明書または公開鍵に直接関連付ける。

バイト列が一致しても、usage の意味は交換できない。usage 1 では証明書材料が一致しても、有効期限切れや不正な PKIX パスを無視できない。usage 3 では、アプリケーション仕様にない Web PKI の規則を自動で追加してはならない。SMTP DANE の機会的セキュリティも、ブラウザの検証モデルをそのまま使うわけではない。

運用判断には、どの usage が、どの署名済みゾーンで、どのサービス向けに公開され、クライアントとアプリケーションがどの失敗規則を実装したかが必要である。

selector は対象を、matching type は比較法を決める

selector 0 は DER 証明書全体、selector 1 は SubjectPublicKeyInfo を選ぶ。同じ鍵で証明書を更新した場合、証明書全体は変わっても SPKI は変わらない可能性がある。

matching type 0 は選択した生バイト、1 は SHA-256、2 は SHA-512 を比較する。十六進値だけを残しても、それが証明書全体なのか公開鍵なのか、あるいはどちらの要約なのか分からない。

完全証明書への関連は対象が狭いが、更新のたびに DNS との同期が必要になる。SPKI は同一鍵での更新を容易にする一方、鍵侵害の影響期間を広げる。トラストアンカーはさらに別の変更範囲を持つ。番号だけで優劣は決まらず、鍵管理と復旧設計が判断を支える。

DNSSEC が secure でなければ DANE 権限は生まれない

形式上正しい type 52 応答を受け取るだけでは足りない。検証器は secure、insecure、bogus、indeterminate を区別しなければならない。Extended DNS Error は診断材料にはなるが、DS、DNSKEY、RRSIG の検証を代行しない。

未署名の TLSA 応答は証明書検証を弱める根拠にならない。逆に、アプリケーションが secure で利用可能な RRset をサービスの約束として扱う場合、一致失敗後に黙って弱い方式へ戻ると downgrade が再び可能になる。SMTP DANE は、利用可能な secure TLSA があるのに認証できないサーバーへ配送することを認めない。

DNSSEC が認証するのは名前の下での公開である。TLS 秘密鍵の独占保有、端点設定の正しさ、業務上の委任までは証明しない。DNS 署名経路と TLS 鍵は別々に侵害され得るため、保管責任と事故証拠も分離すべきである。

一致はアプリケーション許可ではない

TLSA の成功は、ハンドシェイクで提示された選択材料が一つの関連を満たしたことを示す。ALPN が正しいプロトコルを選んだこと、HTTP authority が正当であること、クライアントが認証されたこと、操作が許可されたことまでは示さない。

プロキシが TLS を終端すれば、バックエンドへの接続には新しい証拠が必要になる。機能の異なる複数サーバーが同じ終端証明書を共有すれば、集合内の置換が可能になる。RFC 7672 は、機能的に等価でないサーバー間の共有関連を避けるよう求める。

正確な表現は「この時刻、この TLSA 名の secure usage 3 が提示 SPKI と一致した」である。「ドメインが要求を承認した」ではない。

ローテーションは重複期間として設計する

新しい関連を先に公開し、新旧を同時に保ち、複数のキャッシュとクライアントから観測した後、TTL、署名、端点状態を確認して旧材料を外す。同一鍵での更新、鍵交換、トラストアンカー交換では順序が異なる。

権威サーバーでの公開時刻、再帰キャッシュでの可視性、証明書・鍵の配置、旧材料の削除、RRSIG の有効期間を記録する。一台のリゾルバの成功は全体収束の証明にならない。

境界を越える負の試験

同じ証明書を二つのポートに置き、片方だけ TLSA を公開する。トランスポートを変える。CNAME、SRV、MX の導出を通す。usage 1 で材料を一致させたまま PKIX パスを壊す。同一鍵更新と新鍵更新を別々に試す。

secure、insecure、bogus、indeterminate を作り、最後に TLSA を成功させたまま ALPN またはアプリケーション認可を失敗させる。実装が一つの緑色表示にまとめなければ、境界は保たれている。