1. はじめに (Introduction)
1.1. 背景と動機 (Background and Motivation)
インターネットで通信するアプリケーションは、通信の盗聴、改ざん、偽造を防止する必要があることがよくあります。トランスポート層セキュリティ(TLS)プロトコルは、チャネル暗号化を使用して、インターネット上でこの種の通信セキュリティを提供します。
暗号化システムのセキュリティ特性は、使用する鍵に大きく依存します。秘密鍵が漏洩した場合、または公開鍵が偽の鍵(つまり、証明書で識別されたエンティティに対応しない鍵)に置き換えられた場合、これらのシステムはほとんどまたは全くセキュリティを提供しません。
TLSは証明書を使用して鍵と名前を結び付けます。証明書は、公開鍵と鍵を使用するサービスの名前などの他の情報を組み合わせたもので、この組み合わせは別の鍵によってデジタル署名されます。証明書に鍵があることは、証明書に署名した他の鍵を信頼している場合にのみ役立ちます。その他の鍵自体が漏洩または置き換えられた場合、その署名は最初の鍵について何かを証明する上で価値がありません。
インターネット上では、この問題は「認証局」(CA)と呼ばれるエンティティによって長年解決されてきました。CAは秘密鍵を厳重に保護し、TLSクライアントを構築するソフトウェアベンダーに公開鍵を提供します。次に、証明書に署名し、それらをTLSサーバーに提供します。TLSクライアントソフトウェアは、これらのCA鍵のセットを「トラストアンカー」として使用して、クライアントがTLSサーバーから受信する証明書の署名を検証します。クライアントソフトウェアは通常、任意のCAが他の証明書に有効に署名することを許可します。
TLSが依存している公開CAモデルは根本的に脆弱です。なぜなら、これらのCAのいずれかが任意のドメイン名の証明書を発行できるためです。信頼を裏切る単一の信頼されたCA(自発的に、またはその秘密と機能に対する十分に厳格でない保護を提供することによって)は、TLSで使用される証書が提供するセキュリティを損なう可能性があります。この問題は、侵害されたCAが偽の鍵を含む代替証明書を発行できるために発生します。CAまたはその信頼できるパートナーの侵害に関する最近の経験は、複数の国の政府が何百万人ものユーザーに信頼されている主要なTLS保護されたWebサイトを盗聴および/または破壊しようとするなど、非常に深刻なセキュリティ問題につながっています。
DNSセキュリティ拡張(DNSSEC)は、信頼できる鍵が信頼できない鍵の情報に署名することを含む同様のモデルを提供します。ただし、DNSSECは3つの重要な改善を提供します。鍵は、任意の識別文字列ではなく、ドメインネームシステム(DNS)の名前に結び付けられています。これはインターネットプロトコルにとってより便利です。任意のドメインの署名された鍵は、標準のDNSSECプロトコルを使用した簡単なクエリを通じてオンラインでアクセスできるため、署名された鍵を配布する問題はありません。最も重要なことは、ドメイン名に関連付けられた鍵は、そのドメイン名の親に関連付けられた鍵によってのみ署名できることです。たとえば、「example.com」の鍵は「com」の鍵によってのみ署名でき、「com」の鍵はDNSルートによってのみ署名できます。これにより、信頼できない署名者が自分のサブドメインにあるものを除いて、誰かの鍵を侵害することを防ぎます。TLSと同様に、DNSSECはDNSSECクライアントソフトウェアに組み込まれた公開鍵に依存していますが、これらの鍵は複数のCAからではなく、単一のルートドメインからのみ提供されます。
名前付きエンティティのDNSベース認証(DANE)は、DNSSECインフラストラクチャを使用してTLSが使用する鍵と証明書を保存および署名するオプションを提供します。DANEは、公開鍵データのDNS名への結び付けを保証するエンティティが、問題のDNS名の管理を担当するエンティティと同じであるため、公開鍵をDNS名に結び付けるための好ましい基盤として想定されています。結果として得られるシステムには依然として残留するセキュリティ脆弱性がありますが、DNS階層によって課される命名スコープと一致して、任意のエンティティが行うことができるアサーションのスコープを制限します。その結果、DANEは現在の公開CAモデルに欠けているセキュリティの「最小権限の原則」を体現しています。
1.2. ドメイン名とサーバー証明書の関連付けの保護 (Securing the Association of a Domain Name with a Server's Certificate)
TLSクライアントは、TLSサーバーとメッセージを交換することによって接続を開始します。多くのアプリケーションプロトコルでは、DNSを使用してサーバーの名前を検索し、その名前に関連付けられたインターネットプロトコル(IP)アドレスを取得します。次に、そのアドレスの特定のポートへの接続を開始し、そこに初期メッセージを送信します。ただし、クライアントは、TLSサーバーに到達する前に、敵対者が通信を傍受および/または変更しているかどうかをまだ知りません。そのドメイン名に関連付けられた実際のTLSサーバーが初期メッセージを受信したことがあるかどうかさえわかりません。
TLSでのサーバーからの最初の応答には証明書が含まれている場合があります。TLSクライアントが予想されるTLSサーバーと通信していることを認証するために、クライアントはこの証明書がクライアントがサーバーにアクセスするために使用したドメイン名に関連付けられていることを検証する必要があります。現在、クライアントは証明書からドメイン名を抽出し、トラストアンカーへのチェーンを含む証明書の検証を成功させる必要があります。
外部CAを信頼せずに、サーバーの証明書と意図されたドメイン名との関連付けを認証する別の方法があります。ドメイン名のDNS管理者がゾーンに関する識別情報を提供することが許可されていることを考えると、その管理者がドメイン名とそのドメイン名のホストで使用される可能性のある証明書との間に権威ある結び付けを行うことも許可することは理にかなっています。これを行う最も簡単な方法は、DNSを使用し、DNSSECで結び付けを保護することです。
このような機能には多くのユースケースがあります。[RFC6394]は、このドキュメントのDNS RRtypeが適用されるものをリストしています。[RFC6394]は、このドキュメントが満たすと考えられる多くの要件もリストしています。セクション5では、ユースケースに対するこのドキュメントの適用性について詳しく説明します。このドキュメントのプロトコルは、一般に「DANE TLSA」プロトコルと呼ばれます。(「TLSA」は何も表していません。これは単にRRtypeの名前です。)
このドキュメントは、TLS [RFC5246]とデータグラムTLS(DTLS)[RFC6347]の両方に適用されます。ドキュメントをより読みやすくするために、主に「TLS」についてのみ説明していますが、すべての場合において「TLSまたはDTLS」を意味します。この段落の参照はTLSおよびDTLSバージョン1.2に関するものですが、DANE TLSAプロトコルは以前のバージョンのTLSおよびDTLSでも使用できます。
このドキュメントは、TLSおよびDTLSの証明書をホスト名と安全に関連付けることにのみ関連しています。他のプロトコルのDNSから証明書を取得することは、他のドキュメントで処理されます。たとえば、IPsecの鍵は[RFC4025]で、セキュアシェル(SSH)の鍵は[RFC4255]でカバーされています。
1.3. 証明書の関連付けを保護する方法 (Method for Securing Certificate Associations)
証明書の関連付けは、証明書を識別する情報とサーバーアプリケーションが実行されるドメイン名から形成されます。トラストアンカーとドメイン名の組み合わせも、証明書の関連付けになります。
DNSクエリは、サーバーが1つの証明書から別の証明書に変更している場合など、複数の証明書の関連付けを返すことができます(付録A.4で詳しく説明されています)。
このドキュメントは、PKIX [RFC5280]証明書にのみ適用され、他の形式の証明書には適用されません。
このドキュメントは、TLSサーバーから取得した証明書をDNSを使用してドメイン名に関連付ける安全な方法を定義しています。DNS情報はDNSSECによって保護される必要があります。証明書の関連付けはDNSクエリに基づいて取得されたため、クエリのドメイン名は定義上、証明書に関連付けられています。このドキュメントは、SRV、NAPTR、および同様のDNSリソースレコードに依存するアプリケーションプロトコルのドメイン名に証明書を関連付ける方法についてはカバーしていないことに注意してください。将来のドキュメントでこれらの関連付けを行う方法がカバーされることが予想され、それらのドキュメントはこのドキュメントを更新する必要がある場合とない場合があります。
DNSSEC([RFC4033]、[RFC4034]、および[RFC4035]で定義)は、暗号鍵とデジタル署名を使用してDNSデータの認証を提供します。DNSから取得され、DNSSECを使用して検証された情報は、それによって権威あるデータであることが証明されます。DNSSEC署名は、データの起源の証明を保証するために、DNSSECを使用するすべての応答で検証される必要があります。
このドキュメントは、クライアントが検証されたDNSSEC結果を取得する方法について多くの異なる提案があるため、DNSSEC検証がどのように行われるかを指定していません。たとえば、アプリケーションにコード化されたDNSSEC対応リゾルバ、アプリケーションが実行されているマシン上の信頼できるDNSSECリゾルバ、またはアプリケーションが認証済みおよび完全性保護されたチャネルまたはネットワークを介して通信している信頼できるDNSSECリゾルバからです。これは[RFC4033]のセクション7でより詳しく説明されています。
このドキュメントは、DNSSECを使用して証明書の関連付けのDNS情報を安全に取得することにのみ関連しています。他の安全なDNSメカニズムは範囲外です。
1.4. 用語 (Terminology)
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [RFC2119]で説明されているように解釈されるものとします。
このドキュメントは、標準のPKIX、DNSSEC、TLS、およびDNS用語も使用します。これらの用語については、それぞれ[RFC5280]、[RFC4033]、[RFC5246]、およびSTD 13 [RFC1034] [RFC1035]を参照してください。さらに、TLS保護されたアプリケーションサービスおよびDNS名に関連する用語は[RFC6125]から引用されています。