[要約] RFC 6394は、DNSベースの認証に関する使用例と要件をまとめたものであり、DANEの目的は、信頼性のある認証情報を提供することです。
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 6394 BBN Technologies
Category: Informational October 2011
ISSN: 2070-1721
Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
名前付きエンティティのDNSベースの認証のユースケースと要件（デーン）
Abstract
概要
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names.
多くの現在のアプリケーションは、トランスポートレイヤーセキュリティ（TLS）の証明書ベースの認証機能を使用して、接続されたサーバーが目的のドメイン名を適切に表すことをクライアントが確認できるようにします。通常、この認証は、有名な証明書当局（CAS）に根ざしたPKIX証明書チェーンに基づいていますが、DNS自体を介して追加情報を提供できます。このドキュメントでは、DNSおよびDNSセキュリティ拡張機能（DNSSEC）を使用して、TLS認証プロセスをサポートするアサーションを作成できるユースケースのセットについて説明します。このドキュメントの主な焦点はTLSサーバー認証ですが、TLSクライアントがドメイン名で識別されるアプリケーションのTLSクライアント認証もカバーしています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6394.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6394で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................4
3. Use Cases .......................................................4
3.1. CA Constraints .............................................5
3.2. Service Certificate Constraints ............................6
3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
3.4. Delegated Services .........................................9
4. Other Requirements .............................................10
5. Acknowledgements ...............................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Transport Layer Security (TLS) is used as the basis for security features in many modern Internet application service protocols to provide secure client-server connections [RFC5246]. It underlies secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and provides hop-by-hop security in real-time multimedia and instant-messaging protocols [RFC3261] [RFC6120].
トランスポートレイヤーセキュリティ（TLS）は、多くの最新のインターネットアプリケーションサービスプロトコルのセキュリティ機能の基礎として使用され、安全なクライアントサーバー接続[RFC5246]を提供します。保護されたHTTPおよびセキュアメール[RFC2818] [RFC2595] [RFC3207]の根底にあり、リアルタイムマルチメディアおよびインスタントメサージングプロトコル[RFC3261] [RFC6120]のホップバイホップセキュリティを提供します。
Application service clients typically establish TLS connections to application servers identified by DNS domain names. The process of obtaining this "source" domain is application specific [RFC6125]. The name could be entered by a user or found through an automated discovery process such as an SRV or NAPTR record. After obtaining the address of the server via an A or AAAA DNS record, the client conducts a TLS handshake with the server, during which the server presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
アプリケーションサービスクライアントは通常、DNSドメイン名で識別されたアプリケーションサーバーへのTLS接続を確立します。この「ソース」ドメインを取得するプロセスは、アプリケーション固有の[RFC6125]です。名前は、ユーザーが入力したり、SRVやNAPTRレコードなどの自動発見プロセスを通じて見つけたりすることができます。AまたはAAAA DNSレコードを介してサーバーのアドレスを取得した後、クライアントはサーバーでTLSハンドシェイクを行い、その間にサーバーがPKIX証明書[RFC5280]を提示します。TLSレイヤーはpkixを実行します
validation of the certificate, including verification that the certificate chains to one of the client's trust anchors. If this validation is successful, then the application layer determines whether the DNS name for the application service presented in the certificate matches the source domain name [RFC6125]. Typically, if the name matches, then the client proceeds with the TLS connection.
証明書がクライアントの信頼アンカーのいずれかにチェーンチェーンすることの確認を含む証明書の検証。この検証が成功した場合、アプリケーションレイヤーは、証明書に表示されるアプリケーションサービスのDNS名がソースドメイン名[RFC6125]と一致するかどうかを決定します。通常、名前が一致する場合、クライアントはTLS接続で進行します。
The certificate authorities (CAs) that issue PKIX certificates are asserting bindings between domain names and the public keys they certify. Application service clients are verifying these bindings and making authorization decisions -- whether to proceed with connections -- based on them.
PKIX証明書を発行する証明書当局（CAS）は、ドメイン名と彼らが証明する公開キーの間のバインディングを主張しています。アプリケーションサービスのクライアントは、これらのバインディングを確認し、それらに基づいて接続を進めるかどうかを認証する決定を下しています。
Clients thus rely on CAs to correctly assert bindings between public keys and domain names, in the sense that the holder of the corresponding private key should be the domain holder. Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" certificate from one of the widely used CAs -- a certificate containing the victim application service's domain name and a public key whose corresponding private key is held by the attacker. If the attacker can additionally insert himself as a "man in the middle" between a client and server (e.g., through DNS cache poisoning of an A or AAAA record), then the attacker can convince the client that a server of the attacker's choice legitimately represents the victim's application service.
したがって、クライアントはCASに依存して、対応する秘密鍵の所有者がドメインホルダーであるという意味で、パブリックキーとドメイン名の間のバインディングを正しく主張します。今日、攻撃者は、広く使用されているCAのいずれかから「誤発行」証明書を取得できる場合、特定のアプリケーションサービスドメインとして正常に認証できます。攻撃者によって保持されています。攻撃者がさらに自分自身をクライアントとサーバーの間の「中央の男」として挿入できる場合（たとえば、AまたはAAAAレコードのDNSキャッシュ中毒）、攻撃者はクライアントに攻撃者の選択のサーバーが合法的にいることを納得させることができます被害者の申請サービスを表します。
With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain operator and not tampered with in transit. The goal of technologies for DNS-based Authentication of Named Entities (DANE) is to use the DNS and DNSSEC to provide additional information about the cryptographic credentials associated with a domain, so that clients can use this information to increase the level of assurance they receive from the TLS handshake process. This document describes a set of use cases that capture specific goals for using the DNS in this way, and a set of requirements that the ultimate DANE mechanism should satisfy.
DNSSEC [RFC4033]の出現により、DNS名の解決策は、クライアントがDNS情報がドメイン演算子によって提供され、輸送中に改ざんされていないことを確認できるという意味で、その情報を安全に提供できるようになりました。名前付きエンティティ（DANE）のDNSベースの認証のテクノロジーの目標は、DNSとDNSSECを使用してドメインに関連付けられた暗号化資格情報に関する追加情報を提供することです。TLSハンドシェイクプロセスから。このドキュメントでは、この方法でDNSを使用するための特定の目標をキャプチャする一連のユースケースと、究極のデーンメカニズムが満たすべき一連の要件について説明します。
Finally, it should be noted that although this document will frequently use HTTPS as an example application service, DANE is intended to apply equally to all applications that make use of TLS to connect to application services identified by domain names.
最後に、このドキュメントはhttpsをアプリケーションサービスの例として頻繁に使用するが、DaneはTLSを使用するすべてのアプリケーションに等しく適用して、ドメイン名で識別されたアプリケーションサービスに接続することを目的としていることに注意する必要があります。
This document also makes use of standard PKIX, DNSSEC, and TLS terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC 5246 [RFC5246], respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from RFC 6125 [RFC6125].
このドキュメントでは、標準のPKIX、DNSSEC、およびTLS用語も使用しています。これらの用語については、それぞれRFC 5280 [RFC5280]、RFC 4033 [RFC4033]、およびRFC 5246 [RFC5246]を参照してください。さらに、TLS保護されたアプリケーションサービスとDNS名に関連する用語は、RFC 6125 [RFC6125]から取得されます。
Note in particular that the term "server" in this document refers to the server role in TLS, rather than to a host. Multiple servers of this type may be co-located on a single physical host, often using different ports, and each of these can use different certificates.
特に、このドキュメントの「サーバー」という用語は、ホストではなく、TLSのサーバーの役割を指すことに注意してください。このタイプの複数のサーバーは、多くの場合、異なるポートを使用して単一の物理ホストに共同住宅され、それぞれが異なる証明書を使用できます。
This document refers several times to the notion of a "domain holder". This term is understood to mean the entity that is authorized to control the contents of a particular zone. For example, the registrants of 2nd- or 3rd-level domains are the holders of those domains. The holder of a particular domain is not necessarily the entity that operates the zone.
このドキュメントは、「ドメインホルダー」の概念を何度か参照しています。この用語は、特定のゾーンの内容を制御することが許可されているエンティティを意味すると理解されています。たとえば、2番目または3番目のレベルのドメインの登録者は、それらのドメインの保有者です。特定のドメインの所有者は、必ずしもゾーンを運営するエンティティではありません。
It should be noted that the presence of a valid DNSSEC signature in a DNS reply does not necessarily imply that the records protected by that signature were authorized by the domain holder. The distinction between the holder of a domain and the operator of the corresponding zone has several security implications, which are discussed in the individual use cases below.
DNS返信に有効なDNSSEC署名が存在することは、その署名によって保護されているレコードがドメインホルダーによって承認されたことを必ずしも意味するものではないことに注意する必要があります。ドメインの所有者と対応するゾーンのオペレーターの区別には、以下の個々のユースケースで説明されているいくつかのセキュリティの意味があります。
In this section, we describe the major use cases that the DANE mechanism should support. This list is not intended to represent all possible ways that the DNS can be used to support TLS authentication. Rather, it represents the specific cases that comprise the initial goals for DANE.
このセクションでは、デーンメカニズムがサポートすべき主要なユースケースについて説明します。このリストは、DNSを使用してTLS認証をサポートできるすべての可能な方法を表すことを意図したものではありません。むしろ、デーンの初期目標を構成する特定のケースを表します。
In the use cases below, we will refer to the following dramatis personae:
以下のユースケースでは、次のDramatis personaeを参照します。
Alice: The operator of a TLS-protected application service on the host alice.example.com, and administrator of the corresponding DNS zone.
Alice：ホストAlice.example.comのTLS保護アプリケーションサービスのオペレーターと、対応するDNSゾーンの管理者。
Bob: A client connecting to alice.example.com.
ボブ：Alice.example.comに接続するクライアント。
Charlie: A well-known CA that issues certificates with domain names as identifiers.
チャーリー：識別子としてドメイン名を持つ証明書を発行する有名なCA。
Oscar: An outsourcing provider that operates TLS-protected application services on behalf of customers.
OSCAR：顧客に代わってTLS保護されたアプリケーションサービスを運営するアウトソーシングプロバイダー。
Trent: A CA that issues certificates with domain names as identifiers, but is not generally well-known.
TRENT：識別子としてドメイン名を持つ証明書を発行するが、一般的によく知られていないCA。
These use cases are framed in terms of adding verification steps to TLS server identity checking on the part of application service clients. In application services where the clients are also identified by domain names (e.g., Extensible Messaging and Presence Protocol (XMPP) server-to-server connections), the same considerations and use cases are applicable to the application server's checking of identities in TLS client certificates.
これらのユースケースは、アプリケーションサービスクライアントの側でTLSサーバーIDチェックに確認手順を追加するという点でフレーム化されています。クライアントがドメイン名（例：拡張可能なメッセージとプレゼンスプロトコル（XMPP）サーバーへの接続）によっても識別されるアプリケーションサービスでは、同じ考慮事項とユースケースが、TLSクライアント証明書のアイデンティティのアプリケーションサーバーのチェックに適用できます。。
Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned that other well-known CAs might issue certificates for alice.example.com without her authorization, which clients would accept. Alice would like to provide a mechanism for visitors to her site to know that they should expect alice.example.com to use a certificate issued under the CA that she uses (Charlie) and not another CA. That is, Alice is recommending that the client verify that there is a valid certificate chain from the server certificate to Charlie before accepting the server certificate. (For example, in the TLS handshake, the server might include Charlie's certificate in the server Certificate message's certificate_list structure [RFC5246]).
AliceはAlice.example.comでウェブサイトを運営し、有名なCa Charlieから証明書を取得しました。彼女は、他の有名なCAが、クライアントが受け入れる許可なしにAlice.example.comの証明書を発行する可能性があることを懸念しています。アリスは、彼女のサイトへの訪問者にメカニズムを提供して、Alice.example.comが彼女が使用しているCA（Charlie）の下で発行された証明書を別のCAではなく使用することを期待する必要があることを知りたいと考えています。つまり、アリスは、サーバー証明書を受け入れる前に、サーバー証明書からチャーリーに有効な証明書チェーンがあることをクライアントが確認することを推奨しています。（たとえば、TLSハンドシェイクでは、サーバーにはサーバー証明書メッセージの証明書_LIST構造[RFC5246]にチャーリーの証明書が含まれる場合があります）。
When Bob connects to alice.example.com, he uses this mechanism to verify that the certificate presented by the server was issued under the proper CA, Charlie. Bob also performs the normal PKIX validation procedure for this certificate, in particular verifying that the certificate chains to a trust anchor (possibly Charlie's CA, if Bob accepts Charlie's CA as a trust anchor).
BobがAlice.example.comに接続すると、このメカニズムを使用して、サーバーが提示した証明書が適切なCAであるCharlieの下で発行されたことを確認します。ボブはまた、この証明書の通常のPKIX検証手順を実行します。特に、証明書が信頼アンカーにチェーンを接続することを確認します（おそらく、ボブがチャーリーのCAを信頼アンカーとして受け入れる場合、チャーリーのCA）。
Alice may wish to provide similar information to an external CA operator, Charlie. Prior to issuing a certificate for alice.example.com to someone claiming to be Alice, Charlie needs to verify that Alice is actually requesting a certificate. Alice could indicate her preferred CA using DANE to CAs as well as relying parties. Charlie could then check to see whether Alice said that her certificates should be issued by Charlie or another CA. Note that this check does not guarantee that the precise entity requesting a certification from Charlie actually represents Alice -- only that Alice has authorized Charlie to issue certificates for her domain to properly authorized individuals.
アリスは、外部CAオペレーターのチャーリーに同様の情報を提供したいと考えています。Alice.example.comの証明書をAliceであると主張する誰かに発行する前に、CharlieはAliceが実際に証明書を要求していることを確認する必要があります。アリスは、Daneを使用してCASを使用しているだけでなく、依存しているパーティーを使用していることを示すことができます。チャーリーは、アリスが自分の証明書がチャーリーまたは別のcaによって発行されるべきだと言ったかどうかを確認することができました。このチェックは、チャーリーから認定を要求する正確なエンティティが実際にアリスを表していることを保証するものではないことに注意してください。アリスは、アリスが彼女のドメインの証明書を適切に認可された個人に発行することを許可したことだけです。
In principle, DANE information expressing CA constraints can be presented with or without DNSSEC protection. Presenting DANE information without DNSSEC protection does not introduce any new vulnerabilities, but neither does it add much assurance. Deletion of records removes the protection provided by this constraint, but the client is still protected by CA practices (as now). Injected or modified false records are not useful unless the attacker can also obtain a certificate for the target domain. Thus, in the worst case, tampering with these constraints increases the risk of false authentication to the level that is now standard.
原則として、CAの制約を表現するデーン情報は、DNSSEC保護の有無にかかわらず提示できます。DNSSEC保護なしでデーン情報を提示しても、新しい脆弱性は導入されませんが、それも多くの保証を追加しません。レコードの削除は、この制約によって提供される保護を削除しますが、クライアントはまだCAプラクティスによって保護されています（現在）。攻撃者がターゲットドメインの証明書を取得できない限り、注入または変更された誤った記録は役に立ちません。したがって、最悪の場合、これらの制約を改ざんすることで、現在標準のレベルに誤った認証のリスクが増加します。
Using DANE information for CA constraints without DNSSEC provides a very small incremental security feature. Many common attacks against TLS connections already require the attacker to inject false A or AAAA records in order to steer the victim client to the attacker's server. An attacker that can already inject false DNS records can also provide fake DANE information (without DNSSEC) by simply spoofing the additional records required to carry the DANE information.
DNSSECを使用しないCA制約にDANE情報を使用すると、非常に小さなインクリメンタルセキュリティ機能が提供されます。TLS接続に対する多くの一般的な攻撃では、被害者のクライアントを攻撃者のサーバーに導くために、攻撃者が誤ったAまたはAAAAレコードを注入する必要があります。誤ったDNSレコードを既に挿入できる攻撃者は、デーン情報を運ぶために必要な追加のレコードを単にスプーフィングすることにより、偽のデーン情報（DNSSECなし）を提供することもできます。
Injected or modified false DANE information of this type can be used for denial of service, even if the attacker does not have a certificate for the target domain. If an attacker can modify DNS responses that a target host receives, however, there are already much simpler ways of denying service, such as providing a false A or AAAA record. In this case, DNSSEC is not helpful, since an attacker could still cause a denial of service by blocking all DNS responses for the target domain.
攻撃者がターゲットドメインの証明書を持っていない場合でも、このタイプの注入または変更された誤ったデーン情報は、サービスの拒否に使用できます。ただし、攻撃者がターゲットホストが受信するDNS応答を変更できる場合、誤ったAまたはAAAAレコードを提供するなど、サービスを拒否するよりもはるかに簡単な方法がすでにあります。この場合、攻撃者はターゲットドメインのすべてのDNS応答をブロックすることでサービスの拒否を引き起こす可能性があるため、DNSSECは役に立ちません。
Continuing to require PKIX validation also limits the degree to which DNS operators (as distinct from the holders of domains) can interfere with TLS authentication through this mechanism. As above, even if a DNS operator falsifies DANE records, it cannot masquerade as the target server unless it can also obtain a certificate for the target domain.
PKIXの検証を必要とし続けると、DNS演算子（ドメインの保有者とは異なる）がこのメカニズムを介してTLS認証を妨害できる程度も制限されます。上記のように、たとえDNSオペレーターがDane Recordsを偽造したとしても、ターゲットドメインの証明書を取得できない限り、ターゲットサーバーを仮定することはできません。
Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned about additional, unauthorized certificates being issued by Charlie as well as by other CAs. She would like to provide a way for visitors to her site to know that they should expect alice.example.com to present a specific certificate. In TLS terms, Alice is letting Bob know that this specific certificate must be the first certificate in the server Certificate message's certificate_list structure [RFC5246].
AliceはAlice.example.comでウェブサイトを運営し、有名なCa Charlieから証明書を取得しました。彼女は、チャーリーと他のCASによって発行されている追加の不正な証明書を心配しています。彼女は、彼女のサイトへの訪問者がAlice.example.comが特定の証明書を提示することを期待すべきであることを知る方法を提供したいと考えています。TLSの用語では、アリスはボブに、この特定の証明書がサーバー証明書メッセージの証明書_LIST構造[RFC5246]の最初の証明書でなければならないことを知らせています。
When Bob connects to alice.example.com, he uses this mechanism to verify that the certificate presented by the server is the correct certificate. Bob also performs the normal PKIX validation procedure for this certificate, in particular verifying that the certificate chains to a trust anchor.
BobがAlice.example.comに接続すると、このメカニズムを使用して、サーバーによって提示された証明書が正しい証明書であることを確認します。ボブはまた、この証明書の通常のPKIX検証手順を実行します。特に、証明書が信頼アンカーに連鎖することを確認します。
The security implications for this case are the same as for the "CA Constraints" case above.
このケースのセキュリティへの影響は、上記の「CA制約」ケースの場合と同じです。
Alice would like to be able to generate and use certificates for her website on alice.example.com without involving an external CA at all. Alice can generate her own certificates today, making self-signed certificates and possibly certificates subordinate to those certificates. When Bob receives such a certificate in a TLS handshake, however, he doesn't automatically have a way to verify that the issuer of the certificate is actually Alice, because he doesn't necessarily possess Alice's corresponding trust anchor. This concerns him because an attacker could present a different certificate and perform a man-in-the-middle attack. Bob would like to protect against this.
アリスは、外部CAをまったく伴わずにAlice.example.comで彼女のウェブサイトの証明書を生成して使用できるようにしたいと考えています。アリスは今日、自分の証明書を生成し、自己署名証明書と、これらの証明書に従属する証明書を作成できます。しかし、ボブがTLSの握手でそのような証明書を受け取ったとき、彼は必ずしもアリスの対応する信頼アンカーを持っているわけではないため、証明書の発行者が実際にアリスであることを確認する方法を自動的に持っていません。これは、攻撃者が別の証明書を提示し、中間の攻撃を行うことができるため、彼に関係しています。ボブはこれを守りたいと思っています。
Alice would thus like to publish information so that visitors to her site can know that the certificates presented by her application services are legitimately hers. When Bob connects to alice.example.com, he uses this information to verify that the certificate presented by the server has been issued by Alice. Since Bob can bind certificates to Alice in this way, he can use Alice's CA as a trust anchor for purposes of validating certificates for alice.example.com. Alice can additionally recommend that clients accept only her certificates using the CA constraints described above.
したがって、アリスは情報を公開したいので、彼女のサイトへの訪問者は、彼女のアプリケーションサービスによって提示された証明書が合法的に彼女であることを知ることができます。BobがAlice.example.comに接続すると、この情報を使用して、サーバーが提示した証明書がAliceによって発行されたことを確認します。ボブはこの方法で証明書をアリスにバインドできるため、Alice.example.comの証明書を検証する目的で、アリスのCAを信頼のアンカーとして使用できます。アリスはさらに、上記のCA制約を使用して、クライアントが自分の証明書のみを受け入れることを推奨できます。
As in Section 3.1 above, Alice may wish to represent this information to potential third-party CAs (Charlie) as well as to relying parties (Bob). Since publishing a certificate in a DANE record of this form authorizes the holder of the corresponding private key to represent alice.example.com, a CA that has received a request to issue a certificate from alice.example.com could use the DANE information to verify the requestor's authorization to receive a certificate for that domain. For example, a CA might choose to issue a certificate for a given domain name and public key only when the holder of the domain name has provisioned DANE information with a certificate containing the public key.
上記のセクション3.1のように、アリスはこの情報を潜在的なサードパーティのCAS（チャーリー）および依存パーティー（ボブ）に表現したいと考えています。このフォームのデーンレコードで証明書を公開することで、Alice.example.comを代表する対応する秘密鍵の所有者が認可されているため、Alice.example.comから証明書を発行するリクエストを受け取ったCAは、デーン情報を使用できます。そのドメインの証明書を受け取るという要求者の承認を確認します。たとえば、CAは、ドメイン名の所有者が公開キーを含む証明書をデーン情報にプロビジョニングした場合にのみ、特定のドメイン名と公開キーの証明書を発行することを選択できます。
Note that this use case is functionally equivalent to the case where Alice doesn't issue her own certificates, but uses Trent's CA, which is not well-known. In this case, Alice would be advising Bob that he should treat Trent as a trust anchor for purposes of validating Alice's certificates, rather than a CA operated by Alice herself. Bob would thus need a way to securely obtain Trent's trust anchor information, namely through DANE information.
このユースケースは、アリスが自分の証明書を発行しない場合と機能的に同等であるが、よく知られていないトレントのCAを使用している場合に注意してください。この場合、アリスは、アリス自身が運営するCAではなく、アリスの証明書を検証する目的でトレントを信頼のアンカーとして扱うべきだとボブに助言するでしょう。したがって、ボブはトレントの信頼アンカー情報、つまりデーン情報を安全に取得する方法が必要です。
Alice's advertising of trust anchor material in this way does not guarantee that Bob will accept the advertised trust anchor. For example, Bob might have out-of-band information (such as a pre-existing local policy) that indicates that the CA advertised by Alice (Trent's CA) is not trustworthy, which would lead him to decide not to accept Trent as a trust anchor, and thus to reject Alice's certificate if it is issued under Trent's CA.
この方法でのアリスの信頼アンカー資料の広告は、ボブが宣伝された信頼アンカーを受け入れることを保証するものではありません。たとえば、ボブには、アリス（トレントのCA）が宣伝したCAが信頼できないことを示すバンド外情報（既存のローカルポリシーなど）がある可能性があります。アンカーを信頼するため、トレントのCAの下で発行された場合、アリスの証明書を拒否します。
Providing trust anchor material in this way clearly requires DNSSEC, since corrupted or injected records could be used by an attacker to cause clients to trust an attacker's certificate (assuming that the attacker's certificate is not rejected by some other local policy). Deleted records will only result in connection failure and denial of service, although this could result in clients re-connecting without TLS (a downgrade attack), depending on the application. Therefore, in order for this use case to be safe, applications must forbid clients from falling back to unsecured channels when records appear to have been deleted (e.g., when a missing record has no NSEC or NSEC3 record).
このように信頼できるアンカー資料を提供するには、攻撃者が攻撃者の証明書を信頼させるために攻撃者が破損または挿入された記録を使用することができるため、この方法でTrustアンカー資料を提供するにはDNSSECが明確に必要です（攻撃者の証明書が他のローカルポリシーによって拒否されないと仮定します）。削除されたレコードは、接続の失敗とサービスの拒否にのみ発生する可能性がありますが、アプリケーションに応じて、クライアントがTLS（ダウングレード攻撃）なしで再接続する可能性があります。したがって、このユースケースが安全であるためには、アプリケーションは、レコードが削除されたように見える場合（例：NSECまたはNSEC3レコードがない場合）、クライアントが無担保チャネルに戻ることを禁止する必要があります。
By the same token, this use case puts the most power in the hands of DNS operators. Since the operator of the appropriate DNS zone has de facto control over the content and signing of the zone, he can create false DANE records that bind a malicious party's certificate to a domain. This risk is especially important to keep in mind in cases where the operator of a DNS zone is a different entity than the holder of the domain, as in DNS hosting/outsourcing arrangements, since in these cases the DNS operator might be able to make changes to a domain that are not authorized by the holder of the domain.
同様に、このユースケースは、DNSオペレーターの手に最もパワーをかけます。適切なDNSゾーンのオペレーターは、コンテンツとゾーンの署名を事実上制御しているため、悪意のある当事者の証明書をドメインに結合する誤ったデーンレコードを作成できます。このリスクは、DNSホスティング/アウトソーシングアレンジメントのように、DNSゾーンのオペレーターがドメインの所有者とは異なるエンティティである場合、DNSオペレーターが変更を加えることができる可能性があるため、ドメインの所有者とは異なるエンティティである場合に留意することが特に重要です。ドメインの所有者によって許可されていないドメインへ。
It should be noted that DNS operators already have the ability to obtain certificates for domains under their control, under certain CA policies. In the current system, CAs need to verify that an entity requesting a certificate for a domain is actually the legitimate holder of that domain. Typically, this is done using information published about that domain, such as WHOIS email addresses or special records inserted into a domain. By manipulating these values, it is possible for DNS operators to obtain certificates from some well-known certificate authorities today without authorization from the true domain holder.
DNSオペレーターは、特定のCAポリシーの下で、制御下でドメインの証明書を取得する機能を既に持っていることに注意する必要があります。現在のシステムでは、CASは、ドメインの証明書を要求するエンティティが実際にそのドメインの正当な保有者であることを確認する必要があります。通常、これは、WHOISメールアドレスやドメインに挿入された特別なレコードなど、そのドメインに関する公開された情報を使用して行われます。これらの値を操作することにより、DNSオペレーターは、真のドメインホルダーからの許可なしに、今日有名な証明書当局から証明書を取得することができます。
In addition to guarding against CA mis-issue, CA constraints and certificate constraints can also be used to constrain the set of certificates that can be used by an outsourcing provider. Suppose that Oscar operates alice.example.com on behalf of Alice. In particular, Oscar then has de facto control over what certificates to present in TLS handshakes for alice.example.com. In such cases, there are a few ways that DNS-based information about TLS certificates could be configured; for example:
CAの誤関係を守ることに加えて、CAの制約と証明書の制約を使用して、アウトソーシングプロバイダーが使用できる証明書のセットを制約することもできます。OscarがAlice.example.comをアリスに代わって運営していると仮定します。特に、オスカーは、Alice.example.comのTLSハンドシェイクで提示する証明書を事実上管理しています。そのような場合、TLS証明書に関するDNSベースの情報を構成する方法はいくつかあります。例えば：
1. Alice has the A/AAAA records in her DNS and can sign them along with the DANE record, but Oscar and Alice now need to have tight coordination if the addresses and/or the certificates change.
1. アリスはDNSにA/AAAAレコードを持っており、Dane Recordとともに署名することができますが、オスカーとアリスは、住所や証明書が変更された場合に厳しい調整を行う必要があります。
2. Alice refers to Oscar's DNS by delegating a sub-domain name to Oscar, and has no control over the A/AAAA, DANE, or any other pieces under Oscar's control.
2. アリスは、サブドメイン名をオスカーに委任することにより、オスカーのDNSを指し、A/AAAA、Dane、またはOscarのコントロールの下にあるその他の作品を制御できません。
3. Alice can put DANE records into her DNS server but delegate the address records to Oscar's DNS server. This means that Alice can control the usage of certificates, but Oscar is free to move the servers around as needed. The only coordination needed is when the certificates change, and then it would depend on how the DANE record is set up (i.e., a CA or an end-entity certificate pointer).
3. AliceはDane RecordsをDNSサーバーに入れることができますが、アドレスレコードをOscarのDNSサーバーに委任できます。これは、アリスが証明書の使用を制御できることを意味しますが、オスカーは必要に応じてサーバーを自由に移動できます。必要な唯一の調整は、証明書が変更されたときであり、デーンレコードの設定方法（つまり、CAまたはエンドエンティティ証明書ポインター）に依存します。
Which of these deployment patterns is used in a given deployment will determine what sort of constraints can be expressed by which actors. In cases where Alice controls DANE records (1 and 3), she can use CA and certificate constraints to control what certificates Oscar presents for Alice's application services. For instance, Alice might require Oscar to use certificates under a given set of CAs. This control, however, requires that Alice update DANE records when Oscar needs to change certificates. Cases where Oscar controls DANE records allow Oscar to maintain more autonomy from Alice, but by the same token, Alice cannot enforce any requirements on the certificates that Oscar presents in TLS handshakes.
これらの展開パターンのどれが特定の展開で使用されているのは、どの俳優によってどのような制約を表現できるかを決定します。AliceがDane Records（1および3）を管理する場合、CAと証明書の制約を使用して、Aliceのアプリケーションサービスにオスカーが提示する証明書を制御できます。たとえば、アリスは、オスカーに特定のCASセットの下で証明書を使用することを要求する場合があります。ただし、このコントロールでは、オスカーが証明書を変更する必要がある場合に、アリスがデーンを更新する必要があります。オスカーがDane Recordsを制御する場合、オスカーはアリスからより多くの自律性を維持することができますが、同様に、アリスはオスカーがTLSハンドシェイクで提示する証明書の要件を実施することはできません。
In addition to supporting the above use cases, the DANE mechanism must satisfy several lower-level operational and protocol requirements and goals.
上記のユースケースをサポートすることに加えて、デーンメカニズムは、いくつかの低レベルの運用およびプロトコルの要件と目標を満たす必要があります。
Multiple Ports: DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number.
複数のポート：Daneは、ポート番号で区別される同じ名前のホストに異なる資格情報を持つ複数のアプリケーションサービスをサポートできる必要があります。
No Downgrade: An attacker who can tamper with DNS responses must not be able to make a DANE-compliant client treat a site that has deployed DANE and DNSSEC like a site that has deployed neither.
ダウングレードはありません：DNS応答を改ざんすることができる攻撃者は、Daneに準拠したクライアントにDaneとDNSSECを展開したサイトを展開していないサイトのように扱うことができない必要があります。
Encapsulation: If there is DANE information for the name alice.example.com, it must only affect application services hosted at alice.example.com.
カプセル化：Alice.example.comという名前にDane情報がある場合、Alice.example.comでホストされているアプリケーションサービスのみに影響する必要があります。
Predictability: Client behavior in response to DANE information must be defined in the DANE specification as precisely as possible, especially for cases where DANE information might conflict with PKIX information.
予測可能性：デーン情報に応じたクライアントの動作は、特にDANE情報がPKIX情報と競合する場合がある場合に、DANE仕様で可能な限り正確に定義する必要があります。
Opportunistic Security: The DANE mechanism must allow a client to determine whether DANE information is available for a site, so that a client can provide the highest level of security possible for a given application service. Clients that do not support DANE should continue to work as specified, regardless of whether DANE information is present or not.
日和見的セキュリティ：デーンメカニズムにより、クライアントがサイトでデーン情報が利用可能かどうかを判断できるようにし、クライアントが特定のアプリケーションサービスに可能な限り最高レベルのセキュリティを提供できるようにする必要があります。デーンをサポートしていないクライアントは、デーン情報が存在するかどうかに関係なく、指定どおりに機能し続ける必要があります。
Combination: The DANE mechanism must allow multiple DANE statements of the above forms to be combined. For example, a domain holder should be able to specify that clients should accept a particular certificate (Section 3.2) as well as any certificate issued by its own CA (Section 3.3). The precise types of combination allowed will be defined by the DANE protocol.
組み合わせ：デーンメカニズムは、上記の形式の複数のデーンステートメントを組み合わせることを許可する必要があります。たとえば、ドメインホルダーは、クライアントが特定の証明書（セクション3.2）とそれ自体のCAによって発行された証明書（セクション3.3）を受け入れる必要があることを指定できる必要があります。許可される正確なタイプの組み合わせは、デーンプロトコルによって定義されます。
Roll-over: The DANE mechanism must allow a site to transition from using one DANE mechanism to another. For example, a domain holder should be able to migrate from using DANE to assert a domain-issued certificate (Section 3.3) to using DANE to require an external CA (Section 3.1), or vice versa. The DANE mechanism must also allow roll-over between records of the same type, e.g., when changing CAs.
ロールオーバー：デーンメカニズムにより、サイトが1つのデーンメカニズムを使用して別のメカニズムに移行できるようにする必要があります。たとえば、ドメインホルダーは、DANEを使用してドメイン発行証明書（セクション3.3）を主張することから、外部CA（セクション3.1）を必要とするためにDANEを使用して、またはその逆を必要とするように移行できる必要があります。デーンメカニズムは、同じタイプのレコード間のロールオーバーも許可する必要があります。たとえば、CASを変更するとき。
Simple Key Management: DANE should have a mode in which the domain holder only needs to maintain a single long-lived public/private key pair.
シンプルなキー管理：デーンには、ドメインホルダーが単一の長寿命のパブリック/プライベートキーペアを維持する必要があるモードが必要です。
Minimal Dependencies: It should be possible for a site to deploy DANE without also deploying anything else, except DNSSEC.
最小限の依存関係：DNSSECを除く他のものを展開することなく、サイトがDaneを展開することが可能です。
Minimal Options: Ideally, DANE should have only one operating mode. Practically, DANE should have as few operating modes as possible.
最小限のオプション：理想的には、Daneには1つの動作モードのみが必要です。実際には、Daneにはできるだけ少ない動作モードが必要です。
Wildcards: The mechanism for distributing DANE information should allow the use of DNS wildcard labels (*) for setting DANE information for all names within a wildcard expansion.
ワイルドカード：デーン情報を配布するメカニズムにより、ワイルドカード拡張内のすべての名前のデーン情報を設定するために、DNSワイルドカードラベル（*）を使用できるようにする必要があります。
Redirection: The mechanism for distributing DANE information should work when the application service name is the result of following a DNS redirection chain (e.g., via CNAME or DNAME).
リダイレクト：デーン情報を配布するメカニズムは、アプリケーションサービス名がDNSリダイレクトチェーン（例：CNAMEまたはDNAMEを介して）に従った結果である場合に機能する必要があります。
Thanks to Eric Rescorla for the initial formulation of the use cases, Zack Weinberg and Phillip Hallam-Baker for contributing other requirements, and the whole DANE working group for helpful comments on the mailing list.
ユースケースの初期定式化については、他の要件を貢献してくれたザックワインバーグとフィリップハラムベーカー、およびメーリングリストへの有益なコメントについてはデーンワーキンググループ全体に感謝します。
The primary focus of this document is the enhancement of TLS authentication procedures using the DNS. The general effect of such mechanisms is to increase the role of DNS operators in authentication processes, either in place of or in addition to traditional third-party actors such as commercial certificate authorities. The specific security implications of the respective use cases are discussed in their respective sections above.
このドキュメントの主な焦点は、DNSを使用したTLS認証手順の強化です。このようなメカニズムの一般的な効果は、商業証明書当局などの従来のサードパーティのアクターの代わりに、またはそれに加えて、認証プロセスにおけるDNSオペレーターの役割を増やすことです。それぞれのユースケースの特定のセキュリティへの影響については、上記のそれぞれのセクションで説明します。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「輸送層のセキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、2011年3月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595] Newman、C。、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、2011年3月。
Author's Address
著者の連絡先
Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US
リチャードバーンズBBNテクノロジーズ9861壊れたランドパークウェイコロンビア、メリーランド州21046米国
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com