Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 6394 BBN Technologies
Category: Informational October 2011
ISSN: 2070-1721
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的命名实体身份验证（DANE）的用例和要求
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）中基于证书的身份验证功能，以允许客户端验证连接的服务器是否正确表示所需的域名。通常，此身份验证基于植根于知名证书颁发机构（CA）的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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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证书的证书颁发机构（CA）正在声明域名与其认证的公钥之间的绑定。应用程序服务客户端正在验证这些绑定，并根据这些绑定做出授权决策——是否继续连接。
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.
因此，客户机依赖CA来正确地断言公钥和域名之间的绑定，即相应私钥的持有者应该是域持有者。如今，如果攻击者能够从广泛使用的CA之一获得“错误颁发”的证书，即包含受害者应用程序服务的域名和公钥（其相应的私钥由攻击者持有）的证书，则攻击者可以成功地将其认证为给定的应用程序服务域。如果攻击者还可以将自己作为“中间人”插入客户端和服务器之间（例如，通过DNS缓存中毒a或AAAA记录），则攻击者可以说服客户端，攻击者选择的服务器合法地代表了受害者的应用程序服务。
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信息是由域运营商提供的，并且在传输过程中没有被篡改。基于DNS的命名实体身份验证（DANE）技术的目标是使用DNS和DNSSEC提供有关与域关联的加密凭据的附加信息，以便客户端可以使用此信息来提高他们从TLS握手过程中收到的保证级别。本文档描述了一组用例，这些用例捕获了以这种方式使用DNS的特定目标，以及最终DANE机制应该满足的一组需求。
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.
本文件多次提到“域名持有人”的概念。该术语被理解为指被授权控制特定区域内容的实体。例如，二级或三级域名的注册人是这些域名的持有者。特定领域的持有者不一定是经营该区域的实体。
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.
在本节中，我们将描述DANE机制应该支持的主要用例。此列表并不表示DNS可用于支持TLS身份验证的所有可能方式。相反，它代表了构成丹麦最初目标的具体案例。
In the use cases below, we will refer to the following 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服务器身份检查中添加验证步骤。在客户端也通过域名标识的应用程序服务中（例如，可扩展消息和状态协议（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希望提供一种机制，让其网站的访问者知道他们应该期望Alice.example.com使用她使用的CA（Charlie）下颁发的证书，而不是另一个CA。也就是说，Alice建议客户端在接受服务器证书之前验证从服务器证书到Charlie的证书链是否有效。（例如，在TLS握手中，服务器可能在服务器证书消息的证书列表结构[RFC5246]中包含Charlie的证书）。
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下颁发的。Bob还对此证书执行正常的PKIX验证过程，特别是验证证书是否链接到信任锚点（如果Bob接受Charlie的CA作为信任锚点，则可能是Charlie的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.
Alice可能希望向外部CA运营商Charlie提供类似信息。在向自称是alice的人颁发alice.example.com证书之前，Charlie需要验证alice是否确实在申请证书。Alice可以向CAs以及依赖方表明她使用DANE的首选CA。Charlie然后可以检查Alice是否说她的证书应由Charlie或其他CA颁发。请注意，此检查并不保证请求Charlie颁发证书的确切实体实际上代表Alice——只是Alice已授权Charlie为其域颁发证书以获得适当授权个人。
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约束的DANE信息可以在有或没有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的情况下，将DANE信息用于CA约束可以提供非常小的增量安全功能。许多针对TLS连接的常见攻击已经要求攻击者注入虚假A或AAAA记录，以便将受害客户端引导到攻击者的服务器。已经可以注入虚假DNS记录的攻击者也可以通过简单地欺骗携带DANE信息所需的其他记录来提供虚假的DANE信息（没有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.
即使攻击者没有目标域的证书，这种类型的注入或修改的false DANE信息也可用于拒绝服务。但是，如果攻击者可以修改目标主机接收的DNS响应，则已经有更简单的拒绝服务的方法，例如提供虚假a或AAAA记录。在这种情况下，DNSSEC没有帮助，因为攻击者仍然可以通过阻止目标域的所有DNS响应来造成拒绝服务。
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记录，它也不能伪装成目标服务器，除非它还可以获得目标域的证书。
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获得了证书。她对Charlie以及其他CA颁发的其他未经授权的证书表示担忧。她想为访问她的网站的访问者提供一种方式，让他们知道他们应该期望alice.example.com提供一份特定的证书。在TLS术语中，Alice让Bob知道此特定证书必须是服务器证书消息的证书列表结构[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时，他使用此机制验证服务器提供的证书是否正确。Bob还对此证书执行正常的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.
Alice希望能够在Alice.example.com上为她的网站生成和使用证书，而不需要任何外部CA。Alice现在可以生成自己的证书，使自签名证书和可能的证书从属于这些证书。然而，当Bob在TLS握手中收到这样的证书时，他无法自动验证证书的颁发者实际上是Alice，因为他不一定拥有Alice相应的信任锚。这与他有关，因为攻击者可以提供不同的证书并执行中间人攻击。鲍勃想避免这种情况。
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.
因此，Alice希望发布信息，以便访问她的站点的访问者能够知道她的应用程序服务提供的证书是合法的。当Bob连接到alice.example.com时，他使用此信息验证服务器提供的证书是否由alice颁发。由于Bob可以通过这种方式将证书绑定到Alice，因此他可以使用Alice的CA作为信任锚，以验证Alice.example.com的证书。Alice还可以建议客户端使用上述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节所述，Alice可能希望向潜在的第三方CA（Charlie）以及依赖方（Bob）表示该信息。由于在这种形式的丹麦记录中发布证书授权相应私钥的持有人代表alice.example.com，因此收到alice.example.com颁发证书请求的CA可以使用丹麦信息来验证请求者接收该域证书的授权。例如，CA可能仅在域名持有人已为DANE信息提供了包含公钥的证书时才选择为给定域名和公钥颁发证书。
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.
注意，这个用例在功能上等同于Alice不颁发自己的证书，但使用Trent的CA，这并不广为人知。在这种情况下，Alice会建议Bob将Trent视为验证Alice证书的信任锚，而不是Alice自己操作的CA。因此，Bob需要一种安全获取Trent的信任锚信息的方法，即通过DANE信息。
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.
Alice以这种方式发布的信托锚材料广告并不保证Bob会接受广告中的信托锚。例如，Bob可能有带外信息（如预先存在的本地策略），表明Alice发布的CA（Trent的CA）不可信，这将导致他决定不接受Trent作为信任锚，从而拒绝Alice的证书（如果该证书是在Trent的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).
以这种方式提供信任锚材料显然需要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区域的运营商对区域的内容和签名具有实际控制权，因此他可以创建虚假的DANE记录，将恶意方的证书绑定到域。在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策略为其控制的域获取证书。在当前系统中，CA需要验证请求域证书的实体实际上是该域的合法持有人。通常，这是通过使用发布的有关该域的信息来完成的，例如谁的电子邮件地址或插入到域中的特殊记录。通过操纵这些值，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约束和证书约束还可用于约束外包提供商可以使用的证书集。假设奥斯卡代表爱丽丝运营alice.example.com。特别是，Oscar实际上可以控制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. Alice的DNS中有A/AAAA记录，可以与DANE记录一起签名，但是如果地址和/或证书发生变化，Oscar和Alice现在需要进行密切协调。
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. Alice通过将子域名委托给奥斯卡来引用奥斯卡的DNS，并且对a/AAAA、DANE或奥斯卡控制下的任何其他部分没有控制权。
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记录放入她的DNS服务器，但可以将地址记录委托给Oscar的DNS服务器。这意味着Alice可以控制证书的使用，但Oscar可以根据需要自由移动服务器。唯一需要的协调是证书何时更改，然后它将取决于DANE记录的设置方式（即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记录（1和3）的情况下，她可以使用CA和证书约束来控制Oscar为Alice的应用程序服务提供的证书。例如，Alice可能要求Oscar使用给定CA集下的证书。但是，此控件要求Alice在Oscar需要更改证书时更新DANE记录。奥斯卡控制丹麦记录的案例允许奥斯卡与爱丽丝保持更多的自主权，但出于同样的原因，爱丽丝不能对奥斯卡在TLS握手中出示的证书实施任何要求。
In addition to supporting the above use cases, the DANE mechanism must satisfy several lower-level operational and protocol requirements and goals.
除了支持上述用例外，DANE机制还必须满足几个较低级别的操作和协议需求和目标。
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.
可预测性：必须在丹麦规范中尽可能精确地定义响应丹麦信息的客户端行为，特别是在丹麦信息可能与PKIX信息冲突的情况下。
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.
机会主义安全：DANE机制必须允许客户端确定站点是否有DANE信息，以便客户端能够为给定的应用程序服务提供尽可能高的安全级别。不支持DANE的客户应继续按照规定工作，无论DANE信息是否存在。
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.
组合：DANE机制必须允许组合上述形式的多个DANE声明。例如，域持有人应能够指定客户端应接受特定证书（第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.
滚动：DANE机制必须允许站点从使用一种DANE机制过渡到另一种。例如，域持有人应该能够从使用DANE声明域颁发的证书（第3.3节）迁移到使用DANE要求外部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.
简单密钥管理：DANE应该有一种模式，在这种模式下，域持有者只需要维护一个长期有效的公钥/私钥对。
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应该只有一种操作模式。实际上，丹麦应该有尽可能少的操作模式。
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.
通配符：分发DANE信息的机制应允许使用DNS通配符标签（*）为通配符扩展中的所有名称设置DANE信息。
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）的结果时，分发DANE信息的机制应起作用。
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.
感谢Eric Rescorla对用例的初步表述，感谢Zack Weinberg和Phillip Hallam Baker对其他需求的贡献，感谢整个丹麦工作组对邮件列表的有用意见。
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，“传输层安全（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 52802008年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）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.translate error, please retry
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
Author's Address
作者地址
Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US
Richard Barnes BBN Technologies 9861美国马里兰州哥伦比亚市布罗克兰大道21046号
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com