要約

  • 非zeroのExtSupportLifetimeを記憶できるのは、TLSA authentication chainが検証され、certificate chainとのDANE認証に成功した後だけである。TLSAのTTLとextensionのsupport lifetimeは別のclockとして動く。
  • 有効なTLSA不在証明、insecure delegationの証明、または検証済みzero lifetimeはpinを解除できる。pin中に必要なextensionが単に欠けた場合は証明にならず、clientは接続を止めなければならない。

DNSを使う前にDNS serviceを確かめる

DNS over TLS resolverをDANEで認証するclientは、対象serviceのTLSA RRsetと、それをDNSSEC trust anchorまで結ぶ記録を必要とする。ところが、その検索に使いたいresolverこそ、これから認証しようとしている相手である。RFC 9102はdnssec_chain extensionによって、必要なDNS RRとRRSIGをTLS handshake内でserverからclientへ渡す実験的な方法を定めた。

応答の中には、現在のchainと16-bitのExtSupportLifetimeがある。前者は、SNI nameとportに対応するTLSAが今のcertificateを認証するかを答える。後者は、serverまたは同じnameを担うclusterが、今後何時間このextensionを提供し続けるかを表す。recordの寿命とserviceの約束は同じ数ではない。

RFC 9102の著者はViktor Dukhovni、Shumon Huque、Willem Toorop、Paul Wouters、Melinda Shoreであり、original ideaはAdam Langleyに帰属すると本文が明記する。HuqueのIETF profileと本人のbioは、SalesforceでのDNS infrastructure業務、VerisignとUniversity of Pennsylvaniaでの経歴、networkingとsecurity protocolへの継続的な関与を示す。ここで人物を入口にするのは寄与を追跡するためであって、共同仕様を一人の所有物にするためではない。

Pinの開始には正のchainが要る

clientは、fieldを見ただけではpinしてはならない。non-zero値が効力を持てるのは、extension内のTLSA authentication chainが有効で、serverのcertificate chainに一致し、DANEでhandshake全体が認証されたときだけである。PKIXだけの成功、署名を検証していないRR、あるいは形式だけ正しい応答には、将来を拘束する力がない。

範囲も限定される。requestはTCP portを運び、service nameはclientが送ったSNIから取る。このin-band方式では、serverはそのSNIをCNAME展開して別のbase domainへ置き換えない。pinはnameとportの組に結びつき、同一IPの全virtual hostや同一domainの別serviceには自動で広がらない。

serverが提示した期間は、clientのlocal policyで短くできる。RFCは、侵害されたserverが最大7年を広告する理論的な攻撃を挙げる一方、上限を短くしすぎればdowngrade検出期間も縮むと警告する。実際のpinは、serverのofferとclientのrisk limitが交わるところに成立する。

TTLが切れても約束は切れない

検証済みTLSA RRsetは、受信したTTLの範囲でcacheできる。その間、clientは毎回extensionを求めず、手元のTLSAでserverを認証できる。TTLを過ぎれば同じbytesは使えない。support pinが残っているなら、clientは新しいchainをextensionか別のDNSSEC-validな方法で取得する必要がある。

ここには二つのclockがある。TTLとRRSIG validityは「このchainがいつまでfreshか」を決める。ExtSupportLifetimeは「いつまで新しいchainまたはnegative proofを受け取れるはずか」を決める。RFC 9102が両者を独立させるのは、古い署名を延命するためではなく、期間内にserverがchainを更新する責任を残すためである。

TLS session resumptionはさらに別扱いとなる。再開時にはdnssec_chainが送られず、TLS 1.3ではextensionを載せるCertificate messageも送られない。したがって「extensionなし」を一律にdowngradeと数えるmonitorは誤る。full/resumed handshake、cache expiry、pin expiry、実際に使ったevidenceを一緒に記録しなければならない。

認証済みの不在は、沈黙より強い

domain operatorがTLSAを削除した場合、serverはそのnameとportを覆うNSECまたはNSEC3のauthenticated denialを返せる。clientが検証すれば、既存pinは解除される。secure delegationがなくなったことを示すproofも解除条件になる。その後PKIXへ移るか接続を閉じるかはlocal policyの判断である。

一方、pinが有効でfreshなTLSA cacheもないのにserverがextensionを返さない場合、clientはそれを「TLSAなし」と推測できない。通信をabortまたはdelayし、out-of-bandでvalid TLSAかvalid denialを得なければならない。それにも失敗すればTLS接続を終える。PKIXで通る誤発行certificateを持つrogue serverが、DANE evidenceだけを隠してdowngradeする経路を断つためである。

つまり、extensionを要求することは、TLSAやDANE、DNSSECを永久に要求することではない。zone側はTLSAを削除でき、DSを外してsecure delegationを終えることもできる。ただしpinの残存期間には、変更後の状態を検証可能な形で返す。約束は正の結論を固定せず、答えの来歴を維持する。

廃止はzeroを配ってから始まる

extensionを止めたいserver operatorは、まずDANE-authenticated handshakeでExtSupportLifetimeをzeroにする。その後、過去に配ったnon-zero pinがすべて期限切れになり得る時点までsupportを続け、最後にextensionを無効化する。TLSAやDNSSECを先に外してもよいが、その期間はpinを持つclientへdenial chainを返せなければならない。

hosted serviceでは、この順序を一社だけで決められないことがある。domain ownerはDNSと移転判断を持ち、providerはcertificate、TLS node、chain生成を担う。RFCがnon-zero lifetimeを双方の合意でのみ有効にするよう勧めるのは、この分業があるからだ。clusterの一台が約束を知らなければ、load balancingが間欠的なhard failureを生む。

信頼の起点もserver自身ではない。clientは事前設定したDNSSEC trust anchorからchainを検証し、key rolloverへ追随し、RRSIG時刻を判定できる程度にclockを保つ。in-band deliveryが取り除くのはDNS lookupの依存であり、trust anchorの必要性ではない。

RFC 9102はExperimentalである。TLS WGにはpinningがdeployabilityを複雑にするとの懸念があり、文書はreal-world experimentで確かめるとする。今回のpublic sourceは現在の普及率を示さない。それでも、positive proof、authenticated negative proof、missing responseを分離したstate machineは、他のinfrastructure移行にも通じる厳密さを持つ。

情報源