[要約] RFC 7672は、DANE TLSを使用したSMTPセキュリティのためのDNSベースの認証の要約です。目的は、SMTPセッションの暗号化と認証を強化し、セキュリティの脆弱性を低減することです。
Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7672 Two Sigma
Category: Standards Track W. Hardaker
ISSN: 2070-1721 Parsons
October 2015
SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
Opportunistic DNS-based Authentication of Named Entities（DANE）によるSMTP Security Transport Layer Security（TLS）
Abstract
概要
This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).
このメモは、DNSベースの名前付きエンティティの認証（DANE）TLSA DNSレコードに基づく、メッセージ転送エージェント（MTA）間のSMTPトランスポートセキュリティのダウングレード耐性プロトコルについて説明しています。このプロトコルの採用により、暗号化および認証されたトランスポート層セキュリティ（TLS）を使用するものへのインターネット電子メールバックボーンの段階的な移行が可能になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7672.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7672で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Background .................................................6
1.3. SMTP Channel Security ......................................6
1.3.1. STARTTLS Downgrade Attack ...........................7
1.3.2. Insecure Server Name without DNSSEC .................7
1.3.3. Sender Policy Does Not Scale ........................8
1.3.4. Too Many Certification Authorities ..................9
2. Identifying Applicable TLSA Records .............................9
2.1. DNS Considerations .........................................9
2.1.1. DNS Errors, "Bogus" Responses, and
"Indeterminate" Responses ...........................9
2.1.2. DNS Error Handling .................................11
2.1.3. Stub Resolver Considerations .......................12
2.2. TLS Discovery .............................................13
2.2.1. MX Resolution ......................................14
2.2.2. Non-MX Destinations ................................16
2.2.3. TLSA Record Lookup .................................18
3. DANE Authentication ............................................20
3.1. TLSA Certificate Usages ...................................20
3.1.1. Certificate Usage DANE-EE(3) .......................21
3.1.2. Certificate Usage DANE-TA(2) .......................22
3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
3.2. Certificate Matching ......................................24
3.2.1. DANE-EE(3) Name Checks .............................24
3.2.2. DANE-TA(2) Name Checks .............................24
3.2.3. Reference Identifier Matching ......................25
4. Server Key Management ..........................................26
5. Digest Algorithm Agility .......................................27
6. Mandatory TLS Security .........................................27
7. Note on DANE for Message User Agents ...........................28
8. Interoperability Considerations ................................28
8.1. SNI Support ...............................................28
8.2. Anonymous TLS Cipher Suites ...............................29
9. Operational Considerations .....................................29
9.1. Client Operational Considerations .........................29
9.2. Publisher Operational Considerations ......................30
10. Security Considerations .......................................30
11. References ....................................................31
11.1. Normative References .....................................31
11.2. Informative References ...................................33
Acknowledgements ..................................................34
Authors' Addresses ................................................34
This memo specifies a new connection security model for Message Transfer Agents (MTAs). This model is motivated by key features of inter-domain SMTP delivery, principally, the fact that the destination server is selected indirectly via DNS Mail Exchange (MX) records and that neither email addresses nor MX hostnames signal a requirement for either secure or cleartext transport. Therefore, aside from a few manually configured exceptions, SMTP transport security is, by necessity, opportunistic (for a definition of "Opportunistic Security", see [RFC7435]).
このメモは、メッセージ転送エージェント（MTA）の新しい接続セキュリティモデルを指定します。このモデルは、ドメイン間のSMTP配信の主要な機能、主に、宛先サーバーがDNS Mail Exchange（MX）レコードを介して間接的に選択され、電子メールアドレスもMXホスト名もセキュアまたはクリアテキストトランスポートの要件を通知しないという事実によって動機付けられています。したがって、手動で構成されたいくつかの例外を除いて、SMTPトランスポートセキュリティは必然的に便宜的です（「便宜的セキュリティ」の定義については、[RFC7435]を参照してください）。
This specification uses the presence of DANE TLSA records to securely signal TLS support and to publish the means by which SMTP clients can successfully authenticate legitimate SMTP servers. This becomes "opportunistic DANE TLS" and is resistant to downgrade and man-in-the-middle (MITM) attacks. It enables an incremental transition of the email backbone to authenticated TLS delivery, with increased global protection as adoption increases.
この仕様では、DANE TLSAレコードの存在を使用して、TLSサポートに安全に信号を送信し、SMTPクライアントが正当なSMTPサーバーを正常に認証できる方法を公開しています。これは「日和見DANE TLS」となり、ダウングレードおよび中間者（MITM）攻撃に耐性があります。電子メールバックボーンから認証済みTLS配信への段階的な移行を可能にし、採用が増加するにつれてグローバル保護を強化します。
With opportunistic DANE TLS, traffic from SMTP clients to domains that publish "usable" DANE TLSA records in accordance with this memo is authenticated and encrypted. Traffic from legacy clients or to domains that do not publish TLSA records will continue to be sent in the same manner as before, via manually configured security, (pre-DANE) opportunistic TLS, or just cleartext SMTP.
日和見DANE TLSを使用すると、SMTPクライアントから、このメモに従って「使用可能な」DANE TLSAレコードを発行するドメインへのトラフィックが認証および暗号化されます。レガシークライアントから、またはTLSAレコードを発行しないドメインへのトラフィックは、手動で構成されたセキュリティ、（プレDANE）便宜的TLS、またはクリアテキストSMTPを介して、以前と同じ方法で引き続き送信されます。
Problems with the existing use of TLS in MTA-to-MTA SMTP that motivate this specification are described in Section 1.3. The specification itself follows, in Sections 2 and 3, which describe, respectively, how to locate and use DANE TLSA records with SMTP. In Section 6, we discuss the application of DANE TLS to destinations for which channel integrity and confidentiality are mandatory. In Section 7, we briefly comment on the potential applicability of this specification to Message User Agents.
MTA-to-MTA SMTPでのTLSの既存の使用に関するこの仕様の動機となる問題については、セクション1.3で説明しています。 SMTPでDANE TLSAレコードを見つけて使用する方法をそれぞれ説明するセクション2および3で、仕様自体が続きます。セクション6では、チャネルの整合性と機密性が必須である宛先へのDANE TLSの適用について説明します。セクション7では、メッセージユーザーエージェントに対するこの仕様の潜在的な適用性について簡単にコメントします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
The following terms or concepts are used throughout this document:
このドキュメントでは、次の用語または概念が使用されています。
Man-in-the-middle (MITM) attack: Active modification of network traffic by an adversary able to thereby compromise the confidentiality or integrity of the data.
中間者（MITM）攻撃：攻撃者によるネットワークトラフィックのアクティブな変更により、データの機密性または整合性を損なう可能性があります。
Downgrade attack: (From [RFC4949].) A type of MITM attack in which the attacker can cause two parties, at the time they negotiate a security association, to agree on a lower level of protection than the highest level that could have been supported by both of them.
ダウングレード攻撃：（[RFC4949]から。）MITM攻撃の一種。攻撃者は、セキュリティアソシエーションのネゴシエーション時に2人の当事者に、サポートされている可能性のある最高レベルよりも低いレベルの保護に同意させることができます。それらの両方によって。
Downgrade-resistant: A protocol is "downgrade-resistant" if it employs effective countermeasures against downgrade attacks.
ダウングレード耐性：ダウングレード攻撃に対して効果的な対策を採用している場合、プロトコルは「ダウングレード耐性」です。
"Secure", "bogus", "insecure", "indeterminate": DNSSEC validation results, as defined in Section 4.3 of [RFC4035].
「Secure」、「bogus」、「insecure」、「indeterminate」：[RFC4035]のセクション4.3で定義されているDNSSEC検証結果。
Validating security-aware stub resolver and non-validating security-aware stub resolver: Capabilities of the stub resolver in use, as defined in [RFC4033]; note that this specification requires the use of a security-aware stub resolver.
セキュリティ対応のスタブリゾルバの検証とセキュリティ非対応のスタブリゾルバの検証：[RFC4033]で定義されている、使用中のスタブリゾルバの機能。この仕様では、セキュリティ対応のスタブリゾルバを使用する必要があることに注意してください。
(Pre-DANE) opportunistic TLS: Best-effort use of TLS that is generally vulnerable to DNS forgery and STARTTLS downgrade attacks. When a TLS-encrypted communication channel is not available, message transmission takes place in the clear. MX record indirection generally precludes authentication even when TLS is available.
（プレDANE）日和見TLS：一般にDNS偽造およびSTARTTLSダウングレード攻撃に対して脆弱なTLSのベストエフォート使用。 TLSで暗号化された通信チャネルが使用できない場合、メッセージ送信は平文で行われます。 MXレコードの間接化は、TLSが使用可能な場合でも、一般に認証を排除します。
Opportunistic DANE TLS: Best-effort use of TLS that is resistant to downgrade attacks for destinations with DNSSEC-validated TLSA records. When opportunistic DANE TLS is determined to be unavailable, clients should fall back to pre-DANE opportunistic TLS. Opportunistic DANE TLS requires support for DNSSEC, DANE, and STARTTLS on the client side, and STARTTLS plus a DNSSEC published TLSA record on the server side.
Opportunistic DANE TLS：DNSSEC検証済みのTLSAレコードを持つ宛先へのダウングレード攻撃に耐性のあるTLSのベストエフォート使用。日和見DANE TLSが使用できないと判断された場合、クライアントはDANE以前の日和見TLSにフォールバックする必要があります。 Opportunistic DANE TLSは、クライアント側でのDNSSEC、DANE、およびSTARTTLSのサポートと、サーバー側でのSTARTTLSおよびDNSSEC公開のTLSAレコードのサポートを必要とします。
Reference identifier: (Special case of [RFC6125] definition.) One of the domain names associated by the SMTP client with the destination SMTP server for performing name checks on the server certificate. When name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID (or, if none are present, the [RFC6125] CN-ID) of the server certificate (see Section 3.2.3).
参照識別子：（[RFC6125]定義の特殊なケース。）サーバー証明書の名前チェックを実行するために、SMTPクライアントによって宛先SMTPサーバーに関連付けられたドメイン名の1つ。名前チェックが適用できる場合、少なくとも1つの参照識別子がサーバー証明書の[RFC6125] DNS-ID（存在しない場合は[RFC6125] CN-ID）と一致する必要があります（セクション3.2.3を参照）。
MX hostname: The RRDATA of an MX record consists of a 16 bit preference followed by a Mail Exchange domain name (see [RFC1035], Section 3.3.9). We will use the term "MX hostname" to refer to the latter, that is, the DNS domain name found after the preference value in an MX record. Thus, an "MX hostname" is specifically a reference to a DNS domain name rather than any host that bears that name.
MXホスト名：MXレコードのRRDATAは、16ビットの設定と、それに続くMail Exchangeドメイン名で構成されます（[RFC1035]のセクション3.3.9を参照）。後者、つまりMXレコードの設定値の後にあるDNSドメイン名を指すのに「MXホスト名」という用語を使用します。したがって、「MXホスト名」は、具体的には、その名前を持つホストではなく、DNSドメイン名への参照です。
Delayed delivery: Email delivery is a multi-hop store-and-forward process. When an MTA is unable to forward a message that may become deliverable later, the message is queued and delivery is retried periodically. Some MTAs may be configured with a fallback next-hop destination that handles messages that the MTA would otherwise queue and retry. When a fallback next-hop destination is configured, messages that would otherwise have to be delayed may be sent to the fallback next-hop destination instead. The fallback destination may itself be subject to opportunistic or mandatory DANE TLS (Section 6) as though it were the original message destination.
配信の遅延：メール配信はマルチホップのストアアンドフォワードプロセスです。 MTAが後で配信可能になる可能性のあるメッセージを転送できない場合、メッセージはキューに入れられ、配信は定期的に再試行されます。一部のMTAは、MTAがキューに入れて再試行するメッセージを処理するフォールバックネクストホップ宛先で構成されている場合があります。フォールバックネクストホップの宛先が構成されている場合、遅延させる必要があるメッセージが代わりにフォールバックネクストホップの宛先に送信されることがあります。フォールバック宛先は、それ自体が元のメッセージ宛先であるかのように、日和見的または必須のDANE TLS（セクション6）の対象になる場合があります。
Original next-hop destination: The logical destination for mail delivery. By default, this is the domain portion of the recipient address, but MTAs may be configured to forward mail for some or all recipients via designated relays. The original next-hop destination is, respectively, either the recipient domain or the associated configured relay.
元の次ホップ宛先：メール配信の論理宛先。デフォルトでは、これは受信者アドレスのドメイン部分ですが、MTAは指定されたリレーを介して一部またはすべての受信者にメールを転送するように設定できます。元のネクストホップ宛先は、それぞれ、受信者ドメインまたは関連付けられた構成済みリレーです。
MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
MTA：メッセージ転送エージェント（[RFC5598]、セクション4.3.2）。
MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
MSA：メッセージ送信エージェント（[RFC5598]、セクション4.3.1）。
MUA: Message User Agent ([RFC5598], Section 4.2.1).
MUA：メッセージユーザーエージェント（[RFC5598]、セクション4.2.1）。
RR: A DNS resource record as defined in [RFC1034], Section 3.6.
RR：[RFC1034]のセクション3.6で定義されているDNSリソースレコード。
RRset: An RRset ([RFC2181], Section 5) is a group of DNS resource records that share the same label, class, and type.
RRset：RRset（[RFC2181]、セクション5）は、同じラベル、クラス、タイプを共有するDNSリソースレコードのグループです。
The Domain Name System Security Extensions (DNSSEC) add data origin authentication, data integrity, and data nonexistence proofs to the Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034], and [RFC4035].
ドメインネームシステムセキュリティ拡張機能（DNSSEC）は、データ発信元認証、データ整合性、およびデータ非存在証明をドメインネームシステム（DNS）に追加します。 DNSSECは、[RFC4033]、[RFC4034]、および[RFC4035]で定義されています。
As described in the introduction of [RFC6698], TLS authentication via the existing public Certification Authority (CA) PKI suffers from an overabundance of trusted parties capable of issuing certificates for any domain of their choice. DANE leverages the DNSSEC infrastructure to publish public keys and certificates for use with the Transport Layer Security (TLS) [RFC5246] protocol via the "TLSA" DNS record type. With DNSSEC, each domain can only vouch for the keys of its delegated sub-domains.
[RFC6698]の紹介で説明したように、既存の公的認証局（CA）PKIによるTLS認証は、任意のドメインの証明書を発行できる信頼できる当事者が多すぎるという問題があります。 DANEはDNSSECインフラストラクチャを利用して、「TLSA」DNSレコードタイプを介してトランスポート層セキュリティ（TLS）[RFC5246]プロトコルで使用する公開鍵と証明書を公開します。 DNSSECを使用すると、各ドメインは委任されたサブドメインのキーのみを保証できます。
The TLS protocol enables secure TCP communication. In the context of this memo, channel security is assumed to be provided by TLS. Used without authentication, TLS provides only privacy protection against eavesdropping attacks. Otherwise, TLS also provides data origin authentication to guard against MITM attacks.
TLSプロトコルは安全なTCP通信を可能にします。このメモのコンテキストでは、チャネルセキュリティはTLSによって提供されると想定されています。認証なしで使用されるTLSは、盗聴攻撃に対するプライバシー保護のみを提供します。それ以外の場合、TLSはMITM攻撃から保護するためのデータ発信元認証も提供します。
With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of the many CAs bundled with popular web browsers to allow users to authenticate their "secure" websites. Before we specify a new DANE TLS security model for SMTP, we will explain why a new security model is needed. In the process, we will explain why the familiar HTTPS security model is inadequate to protect inter-domain SMTP traffic.
TLSはHTTPSを使用して、人気のあるWebブラウザーにバンドルされている多くのCAの1つが発行したX.509証明書[RFC5280]を使用して、ユーザーが「安全な」Webサイトを認証できるようにします。 SMTPに新しいDANE TLSセキュリティモデルを指定する前に、新しいセキュリティモデルが必要な理由を説明します。その過程で、よく知られたHTTPSセキュリティモデルがドメイン間SMTPトラフィックを保護するには不十分である理由を説明します。
The subsections below outline four key problems with applying traditional Web PKI [RFC7435] to SMTP; these problems are addressed by this specification. Since an SMTP channel security policy is not explicitly specified in either the recipient address or the MX record, a new signaling mechanism is required to indicate when channel security is possible and should be used. The publication of TLSA records allows server operators to securely signal to SMTP clients that TLS is available and should be used. DANE TLSA makes it possible to simultaneously discover which destination domains support secure delivery via TLS and how to verify the authenticity of the associated SMTP services, providing a path forward to ubiquitous SMTP channel security.
以下のサブセクションでは、従来のWeb PKI [RFC7435]をSMTPに適用する場合の4つの主要な問題について概説しています。これらの問題は、この仕様で対処されています。 SMTPチャネルセキュリティポリシーは、受信者アドレスまたはMXレコードのいずれにも明示的に指定されていないため、チャネルセキュリティがいつ可能であり、使用する必要があるかを示すために、新しいシグナリングメカニズムが必要です。 TLSAレコードの公開により、サーバーオペレーターは、TLSが使用可能であり、使用する必要があることをSMTPクライアントに安全に通知できます。 DANE TLSAは、TLSを介した安全な配信をサポートする宛先ドメインと、関連するSMTPサービスの信頼性を確認する方法を同時に検出し、ユビキタスSMTPチャネルセキュリティへのパスを提供します。
SMTP [RFC5321] is a single-hop protocol in a multi-hop store-and-forward email delivery process. An SMTP envelope recipient address does not correspond to a specific transport-layer endpoint address; rather, at each relay hop, the transport-layer endpoint is the next-hop relay, while the envelope recipient address typically remains the same. Unlike HTTP and its corresponding secured version, HTTPS, where the use of TLS is signaled via the URI scheme, email recipient addresses do not directly signal transport security policy. Indeed, no such signaling could work well with SMTP, since TLS encryption of SMTP protects email traffic on a hop-by-hop basis while email addresses could only express end-to-end policy.
SMTP [RFC5321]は、マルチホップのストアアンドフォワード電子メール配信プロセスにおけるシングルホッププロトコルです。 SMTPエンベロープ受信者アドレスは、特定のトランスポート層エンドポイントアドレスに対応していません。むしろ、各リレーホップでは、トランスポート層エンドポイントはネクストホップリレーですが、エンベロープ受信者アドレスは通常同じままです。 HTTPおよびそれに対応する保護されたバージョンであるHTTPSとは異なり、TLSの使用はURIスキームを介して通知されますが、電子メール受信者アドレスはトランスポートセキュリティポリシーを直接通知しません。実際、SMTPのTLS暗号化はホップバイホップベースで電子メールトラフィックを保護するのに対し、電子メールアドレスはエンドツーエンドのポリシーしか表現できないため、SMTPではこのようなシグナリングはうまく機能しません。
With no mechanism available to signal transport security policy, SMTP relays employ a best-effort "opportunistic" security model for TLS. A single SMTP server TCP listening endpoint can serve both TLS and non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS command [RFC3207]. The server signals TLS support to the client over a cleartext SMTP connection, and, if the client also supports TLS, it may negotiate a TLS-encrypted channel to use for email transmission. The server's indication of TLS support can be easily suppressed by an MITM attacker. Thus, pre-DANE SMTP TLS security can be subverted by simply downgrading a connection to cleartext. No TLS security feature can prevent this. The attacker can simply disable TLS.
トランスポートセキュリティポリシーの信号を送信するメカニズムがないため、SMTPリレーはTLSにベストエフォート型の「日和見的」セキュリティモデルを採用しています。単一のSMTPサーバーTCPリスニングエンドポイントは、TLSクライアントと非TLSクライアントの両方に対応できます。 TLSの使用は、SMTP STARTTLSコマンド[RFC3207]を介してネゴシエートされます。サーバーはクリアテキストSMTP接続を介してクライアントにTLSサポートを通知し、クライアントがTLSもサポートしている場合は、メール送信に使用するTLS暗号化チャネルをネゴシエートする場合があります。サーバーによるTLSサポートの表示は、MITM攻撃者によって簡単に抑制できます。したがって、接続をクリアテキストにダウングレードするだけで、DANE以前のSMTP TLSセキュリティを覆すことができます。これを防ぐことができるTLSセキュリティ機能はありません。攻撃者は単にTLSを無効にすることができます。
With SMTP, DNS MX records abstract the next-hop transport endpoint and allow administrators to specify a set of target servers to which SMTP traffic should be directed for a given domain.
SMTPを使用する場合、DNS MXレコードはネクストホップトランスポートエンドポイントを抽象化し、管理者が特定のドメインへのSMTPトラフィックの送信先となる一連のターゲットサーバーを指定できるようにします。
A TLS client is vulnerable to MITM attacks unless it verifies that the server's certificate binds the public key to a name that matches one of the client's reference identifiers. A natural choice of reference identifier is the server's domain name. However, with SMTP, server names are not directly encoded in the recipient address; instead, they are obtained indirectly via MX records. Without DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning attacks. Active attackers can forge DNS replies with fake MX records and can redirect email to servers with names of their choice. Therefore, secure verification of SMTP TLS certificates matching the server name is not possible without DNSSEC.
TLSクライアントは、サーバーの証明書が公開キーをクライアントの参照識別子の1つと一致する名前にバインドしていることを確認しない限り、MITM攻撃に対して脆弱です。参照識別子の自然な選択は、サーバーのドメイン名です。ただし、SMTPでは、サーバー名は受信者アドレスに直接エンコードされません。代わりに、MXレコードを介して間接的に取得されます。 DNSSECがない場合、MXルックアップはMITMおよびDNSキャッシュポイズニング攻撃に対して脆弱です。アクティブな攻撃者は、偽のMXレコードを使用してDNS応答を偽造し、選択した名前の電子メールをサーバーにリダイレクトできます。したがって、サーバー名に一致するSMTP TLS証明書の安全な検証は、DNSSECなしでは不可能です。
One might try to harden TLS for SMTP against DNS attacks by using the envelope recipient domain as a reference identifier and by requiring each SMTP server to possess a trusted certificate for the envelope recipient domain rather than the MX hostname. Unfortunately, this is impractical, as email for many domains is handled by third parties that are not in a position to obtain certificates for all the domains they serve. Deployment of the Server Name Indication (SNI) extension to TLS (see Section 3 of [RFC6066]) is no panacea, since SNI key management is operationally challenging except when the email service provider is also the domain's registrar and its certificate issuer; this is rarely the case for email.
参照IDとしてエンベロープ受信者ドメインを使用し、MXホスト名ではなくエンベロープ受信者ドメイン用の信頼できる証明書を各SMTPサーバーに要求することにより、DNS攻撃に対してSMTPのTLSを強化しようとする場合があります。残念ながら、これは実用的ではありません。多くのドメインの電子メールは、サービスを提供するすべてのドメインの証明書を取得する立場にないサードパーティによって処理されるためです。 TLSへのサーバー名表示（SNI）拡張の導入（[RFC6066]のセクション3を参照）は万能ではありません。SNIキーの管理は、メールサービスプロバイダーがドメインのレジストラーとその証明書発行者でもある場合を除き、運用上困難です。これは、電子メールにはほとんど当てはまりません。
Since the recipient domain name cannot be used as the SMTP server reference identifier, and neither can the MX hostname without DNSSEC, large-scale deployment of authenticated TLS for SMTP requires that the DNS be secure.
受信者のドメイン名はSMTPサーバー参照識別子として使用できず、MXSECホスト名もDNSSECなしでは使用できないため、SMTPの認証済みTLSを大規模に展開するには、DNSが安全である必要があります。
Since SMTP security depends critically on DNSSEC, it is important to point out that SMTP with DANE is consequently the most conservative possible trust model. It trusts only what must be trusted and no more. Adding any other trusted actors to the mix can only reduce SMTP security. A sender may choose to further harden DNSSEC for selected high-value receiving domains by configuring explicit trust anchors for those domains instead of relying on the chain of trust from the root domain. However, detailed discussion of DNSSEC security practices is out of scope for this document.
SMTPセキュリティはDNSSECに大きく依存しているため、DANEを使用したSMTPは、その結果、最も保守的な信頼モデルであることを指摘することが重要です。信頼する必要があるものだけを信頼し、それ以上は信頼しません。他の信頼できるアクターを追加すると、SMTPセキュリティが低下するだけです。送信者は、ルートドメインからの信頼の連鎖に依存する代わりに、それらのドメインに明示的なトラストアンカーを構成することにより、選択した高価値の受信ドメインのDNSSECをさらに強化することを選択できます。ただし、DNSSECセキュリティプラクティスの詳細な説明は、このドキュメントの範囲外です。
Sending systems are in some cases explicitly configured to use TLS for mail sent to selected peer domains, but this requires configuring sending MTAs with appropriate subject names or certificate content digests from their peer domains. Due to the resulting administrative burden, such statically configured SMTP secure channels are used rarely (generally only between domains that make bilateral arrangements with their business partners). Internet email, on the other hand, requires regularly contacting new domains for which security configurations cannot be established in advance.
送信システムは、選択したピアドメインに送信されるメールにTLSを使用するように明示的に構成されている場合がありますが、これには、ピアドメインからの適切なサブジェクト名または証明書コンテンツダイジェストで送信MTAを構成する必要があります。その結果として生じる管理上の負担のために、そのような静的に構成されたSMTPセキュアチャネルはめったに使用されません（通常、ビジネスパートナーと二国間協定を結ぶドメイン間でのみ）。一方、インターネットメールでは、事前にセキュリティ設定を確立できない新しいドメインに定期的にアクセスする必要があります。
The abstraction of the SMTP transport endpoint via DNS MX records, often across organizational boundaries, limits the use of public CA PKI with SMTP to a small set of sender-configured peer domains. With little opportunity to use TLS authentication, sending MTAs are rarely configured with a comprehensive list of trusted CAs. SMTP services that support STARTTLS often deploy X.509 certificates that are self-signed or issued by a private CA.
DNS MXレコードを介したSMTPトランスポートエンドポイントの抽象化は、多くの場合組織の境界を越えて、SMTPでのパブリックCA PKIの使用を送信者が構成したピアドメインの小さなセットに制限します。 TLS認証を使用する機会がほとんどないため、送信MTAが信頼できるCAの包括的なリストで構成されることはほとんどありません。 STARTTLSをサポートするSMTPサービスは、多くの場合、自己署名またはプライベートCAによって発行されたX.509証明書を展開します。
Even if it were generally possible to determine a secure server name, the SMTP client would still need to verify that the server's certificate chain is issued by a trusted CA (a trust anchor). MTAs are not interactive applications where a human operator can make a decision (wisely or otherwise) to selectively disable TLS security policy when certificate chain verification fails. With no user to "click OK", the MTA's list of public CA trust anchors would need to be comprehensive in order to avoid bouncing mail addressed to sites that employ unknown CAs.
安全なサーバー名を決定することが一般的に可能であったとしても、SMTPクライアントは、サーバーの証明書チェーンが信頼できるCA（トラストアンカー）によって発行されていることを確認する必要があります。 MTAは対話型のアプリケーションではなく、証明書チェーンの検証に失敗した場合、人間のオペレーターが（賢明に、または別の方法で）TLSセキュリティポリシーを選択的に無効にすることを決定できます。 「OK」をクリックするユーザーがいない場合、不明なCAを使用するサイトに宛てられたメールのバウンスを回避するために、MTAのパブリックCAトラストアンカーのリストを包括的にする必要があります。
On the other hand, each trusted CA can issue certificates for any domain. If even one of the configured CAs is compromised or operated by an adversary, it can subvert TLS security for all destinations. Any set of CAs is simultaneously both overly inclusive and not inclusive enough.
一方、信頼できる各CAは、任意のドメインの証明書を発行できます。構成されたCAの1つでも、攻撃者によって侵害または操作された場合、すべての宛先のTLSセキュリティを破壊する可能性があります。 CAのセットは同時に、包括的すぎて包括的ではありません。
An SMTP client that implements opportunistic DANE TLS per this specification depends critically on the integrity of DNSSEC lookups, as discussed in Section 1.3.2. This section lists the DNS resolver requirements needed to avoid downgrade attacks when using opportunistic DANE TLS.
セクション1.3.2で説明されているように、この仕様に従って便宜的DANE TLSを実装するSMTPクライアントは、DNSSECルックアップの整合性に大きく依存します。このセクションでは、日和見DANE TLSを使用するときにダウングレード攻撃を回避するために必要なDNSリゾルバー要件を示します。
A DNS lookup may signal an error or return a definitive answer. A security-aware resolver MUST be used for this specification. Security-aware resolvers will indicate the security status of a DNS RRset with one of four possible values defined in Section 4.3 of [RFC4035]: "secure", "insecure", "bogus", and "indeterminate". In [RFC4035], the meaning of the "indeterminate" security status is:
DNSルックアップは、エラーを通知するか、最終的な回答を返すことがあります。この仕様では、セキュリティ対応のリゾルバを使用する必要があります。セキュリティ対応のリゾルバは、[RFC4035]のセクション4.3で定義された4つの可能な値の1つでDNS RRsetのセキュリティステータスを示します。 [RFC4035]では、「不確定」セキュリティステータスの意味は次のとおりです。
An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.
リゾルバーが必要なDNSSEC RRを取得できないため、リゾルバーがRRsetに署名する必要があるかどうかを判別できないRRset。これは、セキュリティ対応リゾルバが関連するゾーンのセキュリティ対応ネームサーバーに接続できない場合に発生する可能性があります。
Note that the "indeterminate" security status has a conflicting definition in Section 5 of [RFC4033]:
「未確定」のセキュリティステータスの定義は、[RFC4033]のセクション5で矛盾しています。
There is no trust anchor that would indicate that a specific portion of the tree is secure.
ツリーの特定の部分が安全であることを示すトラストアンカーはありません。
In this document, the term "indeterminate" will be used exclusively in the [RFC4035] sense. Therefore, obtaining "indeterminate" lookup results is a (transient) failure condition, namely, the inability to locate the relevant DNS records. DNS records that would be classified "indeterminate" in the sense of [RFC4035] are simply classified as "insecure".
このドキュメントでは、「不確定」という用語は、[RFC4035]の意味でのみ使用されます。したがって、「不確定」なルックアップ結果を取得することは、（一時的な）障害状態です。つまり、関連するDNSレコードを見つけることができません。 [RFC4035]の意味で「不確定」に分類されるDNSレコードは、単に「安全でない」と分類されます。
We do not need to distinguish between zones that lack a suitable ancestor trust anchor, and delegations (ultimately) from a trust anchor that designate a child zone as being "insecure". All "insecure" RRsets MUST be handled identically: in either case, non-validated data for the query domain is all that is and can be available, and authentication using the data is impossible. As the DNS root zone has been signed, we expect that validating resolvers used by Internet-facing MTAs will be configured with trust anchor data for the root zone and that therefore domains with no ancestor trust anchor will not be possible in most deployments.
適切な祖先トラストアンカーがないゾーンと、子ゾーンを「安全でない」と指定するトラストアンカーからの（最終的には）委任を区別する必要はありません。すべての「安全でない」RRsetは同じように処理する必要があります。どちらの場合でも、クエリドメインの検証されていないデータがすべてであり、利用可能であり、データを使用した認証は不可能です。 DNSルートゾーンが署名されているため、インターネットに直接接続するMTAによって使用される検証リゾルバーにはルートゾーンのトラストアンカーデータが構成され、したがって、ほとんどの展開では祖先のトラストアンカーのないドメインは使用できません。
As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus", or "indeterminate". It is expected that most security-aware stub resolvers will not signal an "indeterminate" security status (in the sense of [RFC4035]) to the application and will instead signal a "bogus" or error result. If a resolver does signal an [RFC4035] "indeterminate" security status, this MUST be treated by the SMTP client as though a "bogus" or error result had been returned.
[RFC4035]のセクション4.3に記載されているように、セキュリティ認識DNSリゾルバーは、特定のエラーでないDNS応答が「安全」、「安全でない」、「偽物」、または「不確定」であるかどうかを判別できなければなりません。ほとんどのセキュリティ対応スタブリゾルバは、アプリケーションに「[RFC4035]の意味での）「不確定」セキュリティステータスを通知せず、代わりに「偽の」またはエラー結果を通知することが予想されます。リゾルバが[RFC4035]の「不確定」セキュリティステータスを通知する場合、これは「偽の」またはエラー結果が返されたかのようにSMTPクライアントによって処理される必要があります。
An MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability, if available, to signal DNSSEC validation status based on information the stub resolver has learned from an upstream validating recursive resolver. Security-oblivious stub resolvers [RFC4033] MUST NOT be used. In accordance with Section 4.9.3 of [RFC4035]:
検証しないセキュリティ対応スタブリゾルバを使用するMTAは、スタブリゾルバが上流の検証する再帰リゾルバから学習した情報に基づいてDNSSEC検証ステータスを通知するために、可能であればスタブリゾルバの機能を使用してもよい（MAY）。セキュリティ不明のスタブリゾルバ[RFC4033]を使用してはならない（MUST NOT）。 [RFC4035]のセクション4.9.3に従って：
... a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.
...セキュリティ対応スタブリゾルバは、セキュリティチャネルを介して信頼できるセキュリティ対応再帰ネームサーバーから問題のデータを取得した場合を除き、その代理として実行されたとされる署名検証に依存してはなりません。
To avoid much repetition in the text below, we will pause to explain the handling of "bogus" or "indeterminate" DNSSEC query responses. These are not necessarily the result of a malicious actor; they can, for example, occur when network packets are corrupted or lost in transit. Therefore, "bogus" or "indeterminate" replies are equated in this memo with lookup failure.
以下のテキストで多くの繰り返しを避けるために、一時停止して、「偽の」または「不確定な」DNSSECクエリ応答の処理について説明します。これらは必ずしも悪意のある俳優の結果ではありません。たとえば、ネットワークパケットが破損しているか、転送中に失われた場合に発生します。したがって、このメモでは、「偽の」または「不確定な」応答は、ルックアップの失敗と同等と見なされます。
There is an important non-failure condition we need to highlight in addition to the obvious case of the DNS client obtaining a non-empty "secure" or "insecure" RRset of the requested type. Namely, it is not an error when either "secure" or "insecure" nonexistence is determined for the requested data. When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or nonexistence of the query domain, the response is not a DNS error condition. The DNS client has not been left without an answer; it has learned that records of the requested type do not exist.
DNSクライアントが要求されたタイプの空ではない「安全な」または「安全でない」RRsetを取得する明白なケースに加えて、強調する必要がある重要な非障害条件があります。つまり、要求されたデータに対して「セキュア」または「非セキュア」のいずれかの非存在が判別されても、エラーではありません。 「安全」または「安全でない」検証ステータスのDNSSEC応答が、要求されたタイプのレコードがないか、クエリドメインが存在しないことを報告する場合、応答はDNSエラー状態ではありません。 DNSクライアントは、答えがなければ残されていません。要求されたタイプのレコードが存在しないことがわかりました。
Security-aware stub resolvers will, of course, also signal DNS lookup errors in other cases, for example, when processing a "SERVFAIL" [RFC2136] response code (RCODE) [RFC1035], which will not have an associated DNSSEC status. All lookup errors are treated the same way by this specification, regardless of whether they are from a "bogus" or "indeterminate" DNSSEC status or from a more generic DNS error: the information that was requested cannot be obtained by the security-aware resolver at this time. Thus, a lookup error is either a failure to obtain the relevant RRset if it exists or a failure to determine that no such RRset exists when it does not.
もちろん、セキュリティ対応のスタブリゾルバは、他のケースでもDNSルックアップエラーを通知します。たとえば、 "SERVFAIL" [RFC2136]応答コード（RCODE）[RFC1035]を処理する場合、DNSSECステータスは関連付けられません。すべてのルックアップエラーは、「偽」または「不確定」のDNSSECステータスによるものか、より一般的なDNSエラーによるものかに関わらず、この仕様では同じ方法で処理されます。要求された情報は、セキュリティ対応のリゾルバーでは取得できません。現時点では。したがって、ルックアップエラーは、関連するRRsetが存在する場合にそれを取得できなかったか、存在しない場合にそのようなRRsetが存在しないと判断できなかったかのいずれかです。
In contrast to a "bogus" response or an "indeterminate" response, an "insecure" DNSSEC response is not an error; rather, as explained above, it indicates that the target DNS zone is either delegated as an "insecure" child of a "secure" parent zone or not a descendant of any of the configured DNSSEC trust anchors in use by the SMTP client. "Insecure" results will leave the SMTP client with degraded channel security but do not stand in the way of message delivery. See Section 2.2 for further details.
「偽の」応答または「不確定」応答とは対照的に、「安全でない」DNSSEC応答はエラーではありません。むしろ、上記で説明したように、ターゲットDNSゾーンが「安全な」親ゾーンの「安全でない」子として委任されているか、SMTPクライアントで使用されている構成済みのDNSSECトラストアンカーの子孫ではないことを示しています。 「安全でない」結果では、SMTPクライアントのチャネルセキュリティが低下しますが、メッセージ配信の妨げにはなりません。詳細については、セクション2.2を参照してください。
When a DNS lookup failure (an error, "bogus", or "indeterminate", as defined above) prevents an SMTP client from determining which SMTP server or servers it should connect to, message delivery MUST be delayed. This naturally includes, for example, the case when a "bogus" or "indeterminate" response is encountered during MX resolution. When multiple MX hostnames are obtained from a successful MX lookup but a later DNS lookup failure prevents network address resolution for a given MX hostname, delivery may proceed via any remaining MX hosts.
DNSルックアップの失敗（上記のエラー、「偽」、「不確定」）により、SMTPクライアントが接続先のSMTPサーバーを判別できない場合は、メッセージの配信を遅延させる必要があります。これには、たとえば、MX解決中に「偽の」または「不確定な」応答が発生した場合などが当然含まれます。正常なMXルックアップから複数のMXホスト名が取得されたが、その後のDNSルックアップの失敗により、特定のMXホスト名のネットワークアドレス解決が妨げられた場合、残りのMXホストを介して配信が続行されることがあります。
When a particular SMTP server is securely identified as the delivery destination, a set of DNS lookups (Section 2.2) MUST be performed to locate any related TLSA records. If any DNS queries used to locate TLSA records fail (due to "bogus" or "indeterminate" records, timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP client MUST treat that server as unreachable and MUST NOT deliver the message via that server. If no servers are reachable, delivery is delayed.
特定のSMTPサーバーが配信先として安全に識別されている場合、関連するTLSAレコードを見つけるために一連のDNSルックアップ（セクション2.2）を実行する必要があります。 TLSAレコードを見つけるために使用されるDNSクエリが失敗した場合（「偽の」または「不確定」レコード、タイムアウト、不正な応答、SERVFAIL応答などが原因で）、SMTPクライアントはそのサーバーを到達不能として扱い、メッセージを配信してはなりません（MUST NOT）そのサーバーを介して。到達可能なサーバーがない場合、配信は遅延します。
In the text that follows, we will only describe what happens when all relevant DNS queries succeed. If any DNS failure occurs, the SMTP client MUST behave as described in this section, by "skipping" the SMTP server or destination that is problematic. Queries for candidate TLSA records are explicitly part of "all relevant DNS queries", and SMTP clients MUST NOT continue to connect to an SMTP server or destination whose TLSA record lookup fails.
以下のテキストでは、関連するすべてのDNSクエリが成功した場合にのみ何が起こるかについて説明します。 DNSエラーが発生した場合、SMTPクライアントは、問題のあるSMTPサーバーまたは宛先を「スキップ」することにより、このセクションで説明されているように動作する必要があります。候補のTLSAレコードのクエリは、明示的に「関連するすべてのDNSクエリ」の一部であり、SMTPクライアントは、TLSAレコードの検索に失敗したSMTPサーバーまたは宛先に接続し続けてはなりません（MUST NOT）。
A note about DNAME aliases: a query for a domain name whose ancestor domain is a DNAME alias returns the DNAME RR for the ancestor domain along with a CNAME that maps the query domain to the corresponding sub-domain of the target domain of the DNAME alias [RFC6672]. Therefore, whenever we speak of CNAME aliases, we implicitly allow for the possibility that the alias in question is the result of an ancestor domain DNAME record. Consequently, no explicit support for DNAME records is needed in SMTP software; it is sufficient to process the resulting CNAME aliases. DNAME records only require special processing in the validating stub resolver library that checks the integrity of the combined DNAME + CNAME reply. When DNSSEC validation is handled by a local caching resolver rather than the MTA itself, even that part of the DNAME support logic is outside the MTA.
DNAMEエイリアスに関する注意：祖先ドメインがDNAMEエイリアスであるドメイン名のクエリは、クエリドメインをDNAMEエイリアスのターゲットドメインの対応するサブドメインにマップするCNAMEとともに、祖先ドメインのDNAME RRを返します[RFC6672]。したがって、CNAMEエイリアスについて話すときはいつでも、問題のエイリアスが祖先ドメインのDNAMEレコードの結果である可能性を暗黙のうちに認めています。したがって、SMTPソフトウェアではDNAMEレコードの明示的なサポートは必要ありません。結果のCNAMEエイリアスを処理するだけで十分です。 DNAMEレコードは、DNAME + CNAME応答の組み合わせの整合性をチェックする検証スタブリゾルバーライブラリの特別な処理のみを必要とします。 DNSSEC検証がMTA自体ではなくローカルキャッシングリゾルバーによって処理される場合、DNAMEサポートロジックのその部分でさえMTAの外部にあります。
When a stub resolver returns a response containing a CNAME alias that does not also contain the corresponding query results for the target of the alias, the SMTP client will need to repeat the query at the target of the alias and should do so recursively up to some configured or implementation-dependent recursion limit. If at any stage of CNAME expansion an error is detected, the lookup of the original requested records MUST be considered to have failed.
スタブリゾルバーがエイリアスのターゲットに対応するクエリ結果を含まないCNAMEエイリアスを含む応答を返す場合、SMTPクライアントはエイリアスのターゲットでクエリを繰り返す必要があり、再帰的に構成済みまたは実装依存の再帰制限。 CNAME展開のいずれかの段階でエラーが検出された場合、元の要求されたレコードの検索が失敗したと見なす必要があります。
Whether a chain of CNAME records was returned in a single stub resolver response or via explicit recursion by the SMTP client, if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure", regardless of whether or not any earlier CNAME records leading to the "insecure" record were "secure".
CNAMEレコードのチェーンが単一のスタブリゾルバー応答で返されたか、SMTPクライアントによる明示的な再帰を介して返されたかに関係なく、再帰的な展開のいずれかの段階で「安全でない」CNAMEレコードが検出された場合、それとその後のすべての結果（特に、最終結果）「安全でない」レコードにつながる以前のCNAMEレコードが「安全」であったかどうかに関係なく、「安全でない」と見なされなければなりません（MUST）。
Note that a security-aware non-validating stub resolver may return to the SMTP client an "insecure" reply received from a validating recursive resolver that contains a CNAME record along with additional answers recursively obtained starting at the target of the CNAME. In this case, the only possible conclusion is that some record in the set of records returned is "insecure", and it is, in fact, possible that the initial CNAME record and a subset of the subsequent records are "secure".
セキュリティ対応の非検証スタブリゾルバは、CNAMEレコードを含む検証再帰リゾルバから受信した「安全でない」応答と、CNAMEのターゲットから再帰的に取得された追加の応答をSMTPクライアントに返す場合があることに注意してください。この場合、考えられる唯一の結論は、返されたレコードセットの一部のレコードが「安全でない」ことであり、実際、最初のCNAMEレコードと後続のレコードのサブセットが「安全な」可能性があります。
If the SMTP client needs to determine the security status of the DNS zone containing the initial CNAME record, it will need to issue a separate query of type "CNAME" that returns only the initial CNAME record. Specifically, as discussed in Section 2.2.2, when "insecure" A or AAAA records are found for an SMTP server via a CNAME alias, the SMTP client will need to perform an additional CNAME query in order to determine whether or not the DNS zone in which the alias is published is DNSSEC signed.
SMTPクライアントが初期CNAMEレコードを含むDNSゾーンのセキュリティステータスを判別する必要がある場合、初期CNAMEレコードのみを返すタイプ「CNAME」の別のクエリを発行する必要があります。特に、セクション2.2.2で説明したように、CNAMEエイリアスを介してSMTPサーバーの「安全でない」AまたはAAAAレコードが見つかった場合、SMTPクライアントはDNSゾーンかどうかを判断するために追加のCNAMEクエリを実行する必要があります。エイリアスが公開されているのはDNSSEC署名です。
As noted previously (in Section 1.3.1), opportunistic TLS with SMTP servers that advertise TLS support via STARTTLS is subject to an MITM downgrade attack. Also, some SMTP servers that are not, in fact, TLS capable erroneously advertise STARTTLS by default, and clients need to be prepared to retry cleartext delivery after STARTTLS fails. In contrast, DNSSEC-validated TLSA records MUST NOT be published for servers that do not support TLS. Clients can safely interpret their presence as a commitment by the server operator to implement TLS and STARTTLS.
前述のように（セクション1.3.1）、STARTTLSを介してTLSサポートをアドバタイズするSMTPサーバーを備えた便宜的TLSは、MITMダウングレード攻撃の対象になります。また、実際にはTLSに対応していない一部のSMTPサーバーは、デフォルトで誤ってSTARTTLSをアドバタイズします。クライアントは、STARTTLSが失敗した後にクリアテキスト配信を再試行する準備をする必要があります。対照的に、DNSSEC検証済みのTLSAレコードは、TLSをサポートしないサーバーに対して公開してはなりません（MUST NOT）。クライアントは、その存在をサーバーオペレーターによるTLSおよびSTARTTLSの実装へのコミットメントとして安全に解釈できます。
This memo defines four actions to be taken after the search for a TLSA record returns "secure" usable results, "secure" unusable results, "insecure" or no results, or an error signal. The term "usable" in this context is in the sense of Section 4.1 of [RFC6698]. Specifically, if the DNS lookup for a TLSA record returns:
このメモは、TLSAレコードの検索で「安全な」使用可能な結果、「安全な」使用できない結果、「安全でない」または結果がない、またはエラー信号が返された後に実行する4つのアクションを定義します。この文脈での「使用可能」という用語は、[RFC6698]のセクション4.1の意味です。具体的には、TLSAレコードのDNSルックアップが返された場合：
A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
少なくとも1つの使用可能なレコードを持つ「安全な」TLSA RRset：MTAへの接続では、TLS暗号化を採用しなければならず、このドキュメントの残りで説明する手法を使用してSMTPサーバーを認証しなければなりません（MUST）。認証されたTLS接続の確立に失敗すると、次のSMTPサーバーにフォールバックするか、配信が遅延する必要があります。
A "secure" non-empty TLSA RRset where all the records are unusable: Any connection to the MTA MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
すべてのレコードが使用できない「安全な」空でないTLSA RRset：MTAへの接続はTLSを介して行う必要がありますが、認証は必要ありません。暗号化されたTLS接続の確立に失敗すると、次のSMTPサーバーにフォールバックするか、配信が遅延する必要があります。
An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence of the TLSA records: A connection to the MTA SHOULD be made using (pre-DANE) opportunistic TLS; this includes using cleartext delivery when the remote SMTP server does not appear to support TLS. The MTA MAY retry in cleartext when delivery via TLS fails during the handshake or even during data transfer.
「安全でない」TLSA RRsetまたはDNSSEC認証によるTLSAレコードの存在の拒否：MTAへの接続は、（pre-DANE）日和見TLSを使用して行う必要があります（SHOULD）。これには、リモートSMTPサーバーがTLSをサポートしていないように見える場合のクリアテキスト配信の使用が含まれます。 MTAは、ハンドシェイク中またはデータ転送中にTLS経由の配信が失敗した場合、クリアテキストで再試行する場合があります。
Any lookup error: Lookup errors, including "bogus" and "indeterminate" as explained in Section 2.1.1, MUST result in falling back to the next SMTP server or delayed delivery.
ルックアップエラー：セクション2.1.1で説明されている「偽」および「不確定」を含むルックアップエラーは、次のSMTPサーバーへのフォールバックまたは配信の遅延を引き起こす必要があります。
An SMTP client MAY be configured to mandate DANE-verified delivery for some destinations. With mandatory DANE TLS (Section 6), delivery proceeds only when "secure" TLSA records are used to establish an encrypted and authenticated TLS channel with the SMTP server.
SMTPクライアントは、一部の宛先に対してDANEで検証された配信を義務付けるように構成できます（MAY）。 DANE TLSが必須（セクション6）の場合、SMTPサーバーで暗号化および認証されたTLSチャネルを確立するために「安全な」TLSAレコードが使用される場合にのみ配信が続行されます。
When the original next-hop destination is an address literal rather than a DNS domain, DANE TLS does not apply. Delivery proceeds using any relevant security policy configured by the MTA administrator. Similarly, when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if an MTA chooses to connect to the network address in the nonconformant MX record, DANE TLSA does not apply for such a connection.
元のネクストホップ宛先がDNSドメインではなくアドレスリテラルである場合、DANE TLSは適用されません。配信は、MTA管理者が設定した関連するセキュリティポリシーを使用して続行されます。同様に、MX RRsetがMXホスト名の代わりにネットワークアドレスを誤ってリストする場合、MTAが非準拠MXレコードのネットワークアドレスへの接続を選択すると、DANE TLSAはそのような接続には適用されません。
In the subsections that follow, we explain how to locate the SMTP servers and the associated TLSA records for a given next-hop destination domain. We also explain which name or names are to be used in identity checks of the SMTP server certificate.
次のサブセクションでは、特定のネクストホップ宛先ドメインのSMTPサーバーと関連するTLSAレコードを見つける方法について説明します。また、SMTPサーバー証明書のIDチェックで使用される名前についても説明します。
In this section, we consider next-hop domains that are subject to MX resolution and have MX records. The TLSA records and the associated base domain are derived separately for each MX hostname that is used to attempt message delivery. DANE TLS can authenticate message delivery to the intended next-hop domain only when the MX records are obtained securely via a DNSSEC-validated lookup.
このセクションでは、MX解決の対象であり、MXレコードを持つネクストホップドメインについて検討します。 TLSAレコードと関連するベースドメインは、メッセージ配信の試行に使用されるMXホスト名ごとに個別に取得されます。 DANE TLSは、DNSレコードで検証されたルックアップを介してMXレコードが安全に取得された場合にのみ、目的のネクストホップドメインへのメッセージ配信を認証できます。
MX records MUST be sorted by preference; an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records. In other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel security considerations. Even with two equal-preference MX records, an MTA is not obligated to choose the MX hostname that offers more security. Domains that want secure inbound mail delivery need to ensure that all their SMTP servers and MX records are configured accordingly.
MXレコードは優先順に並べ替える必要があります。 TLSAレコードを持つより悪い（数値的に高い）MXプリファレンスを持つMXホスト名は、TLSAレコードがないより良い（数値的に低い）プリファレンスを持つMXホスト名を横取りしてはなりません（MUST）。言い換えれば、MXの設定に従うことによる配信ループの防止は、チャネルのセキュリティの考慮事項よりも優先されなければなりません。優先度が同じMXレコードが2つある場合でも、MTAはより高いセキュリティを提供するMXホスト名を選択する義務はありません。安全な受信メール配信を希望するドメインは、すべてのSMTPサーバーとMXレコードが適切に設定されていることを確認する必要があります。
In the language of [RFC5321], Section 5.1, the original next-hop domain is the "initial name". If the MX lookup of the initial name results in a CNAME alias, the MTA replaces the initial name with the resulting name and performs a new lookup with the new name. MTAs typically support recursion in CNAME expansion, so this replacement is performed repeatedly (up to the MTA's recursion limit) until the ultimate non-CNAME domain is found.
[RFC5321]の言語、セクション5.1では、元のネクストホップドメインは「初期名」です。初期名のMXルックアップでCNAMEエイリアスが発生した場合、MTAは初期名を結果の名前に置き換え、新しい名前で新しいルックアップを実行します。 MTAは通常、CNAME拡張での再帰をサポートしているため、この置換は、最終的な非CNAMEドメインが見つかるまで（MTAの再帰制限まで）繰り返し実行されます。
If the MX RRset (or any CNAME leading to it) is "insecure" (see Section 2.1.1) and DANE TLS for the given destination is mandatory (Section 6), delivery MUST be delayed. If the MX RRset is "insecure" and DANE TLS is not mandatory, the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).
MX RRset（またはそれにつながる任意のCNAME）が「安全でない」（セクション2.1.1を参照）で、指定された宛先のDANE TLSが必須（セクション6）である場合、配信は遅延する必要があります。 MX RRsetが「安全ではない」で、DANE TLSが必須ではない場合、SMTPクライアントは、DAN以前の便宜的TLS（おそらくクリアテキスト）を自由に使用できます。
Since the protocol in this memo is an Opportunistic Security protocol [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below), even with MX hosts obtained via an "insecure" MX RRset. For example, when a hosting provider has a signed DNS zone and publishes TLSA records for its SMTP servers, hosted domains that are not signed may still benefit from the provider's TLSA records. Deliveries via the provider's SMTP servers will not be subject to active attacks when sending SMTP clients elect to use the provider's TLSA records (active attacks that tamper with the "insecure" MX RRset are of course still possible in this case).
このメモのプロトコルはOpportunistic Securityプロトコル[RFC7435]であるため、SMTPクライアントは、「安全でない」MX RRset経由で取得されたMXホストでもDANE TLSを使用することを選択できます（セクション2.2.2を参照）。たとえば、ホスティングプロバイダーが署名済みDNSゾーンを持ち、そのSMTPサーバーのTLSAレコードを公開している場合でも、署名されていないホストドメインは、プロバイダーのTLSAレコードの恩恵を受ける可能性があります。プロバイダーのSMTPサーバーを介した配信は、SMTPクライアントの送信時にプロバイダーのTLSAレコードを使用することを選択した場合、アクティブな攻撃を受けません（この場合、「安全でない」MX RRsetを改ざんするアクティブな攻撃はもちろん可能です）。
When the MX records are not (DNSSEC) signed, an active attacker can redirect SMTP clients to MX hosts of his choice. Such redirection is tamper-evident when SMTP servers found via "insecure" MX records are recorded as the next-hop relay in the MTA delivery logs in their original (rather than CNAME-expanded) form. Sending MTAs SHOULD log unexpanded MX hostnames when these result from "insecure" MX lookups. Any successful authentication via an insecurely determined MX host MUST NOT be misrepresented in the mail logs as secure delivery to the intended next-hop domain.
MXレコードが（DNSSEC）署名されていない場合、アクティブな攻撃者は任意のMXホストにSMTPクライアントをリダイレクトできます。このようなリダイレクトは、「安全でない」MXレコードを介して検出されたSMTPサーバーがネクストホップリレーとして（CNAME展開ではなく）元の形式でMTA配信ログに記録された場合に改ざんされます。 MTAを送信すると、拡張されていないMXホスト名が「安全でない」MXルックアップの結果である場合にログに記録する必要があります（SHOULD）。安全でないと判断されたMXホストを介した認証の成功は、意図されたネクストホップドメインへの安全な配信としてメールログに誤って表示されてはなりません。
In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure", then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2. When, for a given MX hostname, no TLSA records are found or only "insecure" TLSA records are found, DANE TLSA is not applicable with the SMTP server in question, and delivery proceeds to that host as with pre-DANE opportunistic TLS. To avoid downgrade attacks, any errors during TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP server in question to be treated as unreachable.
DNSルックアップエラーがない場合（セクション2.1.1）、MX RRsetが「安全でない」場合、それは「安全」であり、SMTPクライアントはセクション2.2.2で説明されているように各MXホスト名を処理する必要があります。特定のMXホスト名に対して、TLSAレコードが見つからないか、「安全でない」TLSAレコードのみが見つかった場合、DANE TLSAは問題のSMTPサーバーには適用できず、DANEより前の日和見TLSと同様に、そのホストに配信が進みます。ダウングレード攻撃を回避するには、セクション2.1.2で説明されているように、TLSAルックアップ中にエラーが発生すると、問題のSMTPサーバーが到達不能として処理される必要があります。
This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution, that represents a hostname from a "secure" MX RRset, or that lacks MX records. Such domains include:
このセクションでは、MX解決の対象ではない、「安全な」MX RRsetからのホスト名を表す、またはMXレコードがない、入力ドメインのTLSAレコードと関連するTLSAベースドメインを見つけるために使用されるアルゴリズムについて説明します。そのようなドメインは次のとおりです。
o Any host that is configured by the sending MTA administrator as the next-hop relay for some or all domains and that is not subject to MX resolution.
o 送信側MTA管理者が一部またはすべてのドメインのネクストホップリレーとして構成し、MX解決の対象にならないホスト。
o A domain that has MX records. When a domain has MX records, we treat each MX host listed in those MX records as though it were a non-MX destination -- that is, in the same way as we would treat an administrator-configured relay that handles mail for that domain. (Unlike administrator-specified relays, MTAs are not required to support CNAME expansion of next-hop names found via MX lookups.)
o MXレコードを持つドメイン。ドメインにMXレコードがある場合、それらのMXレコードにリストされている各MXホストを、それが非MX宛先であるかのように扱います。つまり、そのドメインのメールを処理する管理者設定のリレーを扱うのと同じ方法です。 。 （管理者指定のリレーとは異なり、MTAはMXルックアップを介して見つかったネクストホップ名のCNAME拡張をサポートする必要はありません。）
o A next-hop destination domain subject to MX resolution that has no MX records. In this case, the domain's name is implicitly also its sole SMTP server name.
o MXレコードがないMX解決の対象となるネクストホップ宛先ドメイン。この場合、ドメイン名は暗黙的にその唯一のSMTPサーバー名でもあります。
Note that DNS queries with type TLSA are mishandled by load-balancing nameservers that serve the MX hostnames of some large email providers. The DNS zones served by these nameservers are not signed and contain no TLSA records. These nameservers SHOULD provide "insecure" negative replies that indicate the nonexistence of the TLSA records, but instead they fail by not responding at all or by responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g., SERVFAIL or NOTIMP [RFC2136].
タイプがTLSAのDNSクエリは、一部の大規模な電子メールプロバイダーのMXホスト名を提供する負荷分散ネームサーバーによって誤って処理されることに注意してください。これらのネームサーバーによって提供されるDNSゾーンは署名されておらず、TLSAレコードを含みません。これらのネームサーバーは、TLSAレコードが存在しないことを示す「安全でない」否定応答を提供する必要がありますが、代わりに、まったく応答しないか、NXDOMAIN以外のDNS RCODE [RFC1035]で応答することで失敗します（SERVFAILやNOTIMP [RFC2136]など）。
To avoid problems delivering mail to domains whose SMTP servers are served by these problematic nameservers, the SMTP client MUST perform any A and/or AAAA queries for the destination before attempting to locate the associated TLSA records. This lookup is needed in any case to determine (1) whether or not the destination domain is reachable and (2) the DNSSEC validation status of the chain of CNAME queries required to reach the ultimate address records.
SMTPサーバーがこれらの問題のあるネームサーバーによってサービスを提供されているドメインにメールを配信する問題を回避するために、SMTPクライアントは、関連するTLSAレコードの検索を試みる前に、宛先に対してAまたはAAAAクエリを実行する必要があります。この検索は、（1）宛先ドメインに到達できるかどうか、および（2）最終的なアドレスレコードに到達するために必要なCNAMEクエリのチェーンのDNSSEC検証ステータスを決定するために必要です。
If no address records are found, the destination is unreachable. If address records are found but the DNSSEC validation status of the first query response is "insecure" (see Section 2.1.3), the SMTP client SHOULD NOT proceed to search for any associated TLSA records. In the case of these problematic domains, TLSA queries would lead to DNS lookup errors and would cause messages to be consistently delayed and ultimately returned to the sender. We don't expect to find any
住所レコードが見つからない場合は、宛先に到達できません。アドレスレコードが見つかったが、最初のクエリ応答のDNSSEC検証ステータスが「安全でない」（セクション2.1.3を参照）場合、SMTPクライアントは、関連するTLSAレコードの検索を続行すべきではありません（SHOULD NOT）。これらの問題のあるドメインの場合、TLSAクエリはDNSルックアップエラーにつながり、メッセージが一貫して遅延し、最終的に送信者に返される原因になります。私たちは何かを見つけることを期待していません
"secure" TLSA records associated with a TLSA base domain that lies in an unsigned DNS zone. Therefore, skipping TLSA lookups in this case will also reduce latency, with no detrimental impact on security.
署名されていないDNSゾーンにあるTLSA基本ドメインに関連付けられた「安全な」TLSAレコード。したがって、この場合にTLSAルックアップをスキップするとレイテンシも短縮され、セキュリティに悪影響を与えることはありません。
If the A and/or AAAA lookup of the initial name yields a CNAME, we replace it with the resulting name as if it were the initial name and perform a lookup again using the new name. This replacement is performed recursively (up to the MTA's recursion limit).
初期名のAまたはAAAAルックアップ、あるいはその両方でCNAMEが生成される場合、それを結果の名前に置き換えて、それが初期名であるかのようにして、新しい名前を使用して再度ルックアップを実行します。この置換は再帰的に実行されます（MTAの再帰制限まで）。
We consider the following cases for handling a DNS response for an A or AAAA DNS lookup:
AまたはAAAA DNSルックアップのDNS応答を処理する次のケースを検討します。
Not found: When the DNS queries for A and/or AAAA records yield neither a list of addresses nor a CNAME (or CNAME expansion is not supported), the destination is unreachable.
見つかりません：AレコードまたはAAAAレコード、あるいはその両方のDNSクエリがアドレスのリストもCNAMEも生成しない場合（またはCNAME展開はサポートされていません）、宛先に到達できません。
Non-CNAME: The answer is not a CNAME alias. If the address RRset is "secure", TLSA lookups are performed as described in Section 2.2.3 with the initial name as the candidate TLSA base domain. If no "secure" TLSA records are found, DANE TLS is not applicable and mail delivery proceeds with pre-DANE opportunistic TLS (which, being best-effort, degrades to cleartext delivery when STARTTLS is not available or the TLS handshake fails).
CNAME以外：回答はCNAMEエイリアスではありません。アドレスRRsetが「セキュア」である場合、TLSAルックアップは、セクション2.2.3で説明されているように、候補のTLSAベースドメインとして初期名を使用して実行されます。 「安全な」TLSAレコードが見つからない場合、DANE TLSは適用されず、メール配信はDANEより前の便宜的なTLSで続行されます（これはベストエフォートであり、STARTTLSが利用できない場合やTLSハンドシェイクが失敗した場合にクリアテキスト配信に低下します）。
Insecure CNAME: The input domain is a CNAME alias, but the ultimate network address RRset is "insecure" (see Section 2.1.1). If the initial CNAME response is also "insecure", DANE TLS does not apply. Otherwise, this case is treated just like the non-CNAME case above, where a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain.
安全でないCNAME：入力ドメインはCNAMEエイリアスですが、最終的なネットワークアドレスRRsetは「安全ではありません」（セクション2.1.1を参照）。最初のCNAME応答も「安全でない」場合、DANE TLSは適用されません。それ以外の場合、このケースは上記のCNAME以外のケースと同様に扱われ、元の入力ドメインを候補TLSAベースドメインとしてTLSAレコードを検索します。
Secure CNAME: The input domain is a CNAME alias, and the ultimate network address RRset is "secure" (see Section 2.1.1). Two candidate TLSA base domains are tried: the fully CNAME-expanded initial name and, failing that, the initial name itself.
セキュアCNAME：入力ドメインはCNAMEエイリアスであり、最終的なネットワークアドレスRRsetは「セキュア」です（セクション2.1.1を参照）。 2つのTLSA基本ドメイン候補が試されます。完全にCNAMEで拡張された初期名と、失敗した場合は、初期名自体です。
In summary, if it is possible to securely obtain the full, CNAME-expanded, DNSSEC-validated address records for the input domain, then that name is the preferred TLSA base domain. Otherwise, the unexpanded input domain is the candidate TLSA base domain. When no "secure" TLSA records are found at either the CNAME-expanded or unexpanded domain, then DANE TLS does not apply for mail delivery via the input domain in question. And, as always, errors, "bogus" results, or "indeterminate" results for any query in the process MUST result in delaying or abandoning delivery.
要約すると、入力ドメインのCNAME拡張されたDNSSEC検証済みの完全なアドレスレコードを安全に取得できる場合、その名前が優先TLSA基本ドメインになります。それ以外の場合、拡張されていない入力ドメインはTLSA基本ドメインの候補です。 「安全な」TLSAレコードがCNAME拡張ドメインまたは非拡張ドメインのいずれかで見つからない場合、DANE TLSは問題の入力ドメインを介したメール配信には適用されません。そして、いつものように、プロセス内のクエリのエラー、「偽の」結果、または「不確定な」結果は、配信の遅延または中止を引き起こす必要があります。
When the SMTP server's hostname is not a CNAME or DNAME alias, the list of associated candidate TLSA base domains (see below) consists of just the server hostname.
SMTPサーバーのホスト名がCNAMEまたはDNAMEエイリアスではない場合、関連する候補TLSAベースドメイン（以下を参照）のリストはサーバーホスト名のみで構成されます。
When the hostname is an alias with a "secure" (at every stage) full expansion, the list of candidate TLSA base domains (see below) is a pair of domains: the fully expanded server hostname first, and the unexpanded server hostname second.
ホスト名が「安全」な（すべての段階で）完全に拡張されたエイリアスである場合、候補TLSAベースドメイン（以下を参照）のリストはドメインのペアです：最初に完全に拡張されたサーバーホスト名、2番目に拡張されていないサーバーホスト名。
Each candidate TLSA base domain (alias-expanded or original) is in turn prefixed with service labels of the form "_<port>._tcp". The resulting domain name is used to issue a DNSSEC query with the query type set to TLSA ([RFC6698], Section 7.1).
候補となる各TLSAベースドメイン（エイリアス拡張またはオリジナル）には、 "_ <port> ._ tcp"という形式のサービスラベルが前に付けられます。結果のドメイン名は、クエリタイプをTLSAに設定してDNSSECクエリを発行するために使用されます（[RFC6698]、セクション7.1）。
The first of these candidate domains to yield a "secure" TLSA RRset becomes the actual TLSA base domain.
「安全な」TLSA RRsetを生成するこれらの候補ドメインの最初は、実際のTLSA基本ドメインになります。
For SMTP, the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator, in which case the SMTP client MUST use the appropriate number in the "_<port>" prefix in place of "_25". If, for example, the candidate base domain is "mx.example.com" and the SMTP connection is to port 25, the TLSA RRset is obtained via a DNSSEC query of the form:
SMTPの場合、宛先TCPポートは通常25ですが、MTA管理者によって指定されたカスタムルートとは異なる場合があります。その場合、SMTPクライアントは、「_ <ポート>」接頭辞に「_25」の代わりに適切な番号を使用する必要があります。 」たとえば、ベースドメインの候補が「mx.example.com」で、SMTP接続がポート25である場合、TLSA RRsetは次の形式のDNSSECクエリを介して取得されます。
_25._tcp.mx.example.com. IN TLSA ?
_25._tcp.mx.example.com。 TLSAで？
The query response may be a CNAME or the actual TLSA RRset. If the response is a CNAME, the SMTP client (through the use of its security-aware stub resolver) restarts the TLSA query at the target domain, following CNAMEs as appropriate, and keeps track of whether or not the entire chain is "secure". If any "insecure" records are encountered or the TLSA records don't exist, the next candidate TLSA base domain is tried instead.
クエリの応答は、CNAMEまたは実際のTLSA RRsetの場合があります。応答がCNAMEの場合、SMTPクライアントは（そのセキュリティ対応スタブリゾルバーを使用して）必要に応じてCNAMEに従い、ターゲットドメインでTLSAクエリを再起動し、チェーン全体が「安全」であるかどうかを追跡します。 「安全でない」レコードが検出された場合、またはTLSAレコードが存在しない場合は、代わりに次の候補TLSAベースドメインが試行されます。
If the ultimate response is a "secure" TLSA RRset, then the candidate TLSA base domain will be the actual TLSA base domain, and the TLSA RRset will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records, then the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).
最終的な応答が「安全な」TLSA RRsetである場合、候補のTLSA基本ドメインは実際のTLSA基本ドメインであり、TLSA RRsetは宛先のTLSAレコードを構成します。候補のTLSA基本ドメインのいずれも「安全な」TLSAレコードを生成しない場合、SMTPクライアントは、DAN以前の便宜的TLS（おそらくはクリアテキスト）を自由に使用できます。
TLSA record publishers may leverage CNAMEs to reference a single authoritative TLSA RRset specifying a common CA or a common end-entity certificate to be used with multiple TLS services. Such CNAME expansion does not change the SMTP client's notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is a CNAME, the base domain remains mx.example.com, and this is still the reference identifier used together with the next-hop domain in peer certificate name checks.
TLSAレコードの発行者は、CNAMEを利用して、複数のTLSサービスで使用される共通のCAまたは共通のエンドエンティティ証明書を指定する単一の信頼できるTLSA RRsetを参照できます。このようなCNAMEの拡張は、SMTPクライアントのTLSAベースドメインの概念を変更しません。したがって、_25._tcp.mx.example.comがCNAMEである場合、ベースドメインはmx.example.comのままであり、これは引き続きピア証明書名チェックでネクストホップドメインと一緒に使用される参照識別子です。
Note that shared end-entity certificate associations expose the publishing domain to substitution attacks, where an MITM attacker can reroute traffic to a different server that shares the same end-entity certificate. Such shared end-entity TLSA records SHOULD be avoided unless the servers in question are functionally equivalent or employ mutually incompatible protocols (an active attacker gains nothing by diverting client traffic from one such server to another).
共有エンドエンティティ証明書の関連付けにより、発行ドメインが置換攻撃にさらされることに注意してください。MITM攻撃者は、同じエンドエンティティ証明書を共有する別のサーバーにトラフィックを再ルーティングできます。このような共有エンドエンティティのTLSAレコードは、問題のサーバーが機能的に同等であるか、相互に互換性のないプロトコルを使用している場合を除き、避ける必要があります（アクティブな攻撃者は、クライアントトラフィックをそのようなサーバーから別のサーバーに転送することによって何も得ません）。
A better example, employing a shared trust anchor rather than shared end-entity certificates, is illustrated by the DNSSEC-validated records below:
共有のエンドエンティティ証明書ではなく共有のトラストアンカーを使用するより良い例を、以下のDNSSEC検証済みレコードで示します。
example.com. IN MX 0 mx1.example.com. example.com. IN MX 0 mx2.example.com. _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com. _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com. tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
example.com。 IN MX 0 mx1.example.com。 example.com。 IN MX 0 mx2.example.com。 _25._tcp.mx1.example.com。 CNAME tlsa201._dane.example.com。 _25._tcp.mx2.example.com。 CNAME tlsa201._dane.example.com。 tlsa201._dane.example.com。 IN TLSA 2 0 1 e3b0c44298fc1c149a ...
The SMTP servers mx1.example.com and mx2.example.com will be expected to have certificates issued under a common trust anchor, but each MX hostname's TLSA base domain remains unchanged despite the above CNAME records. Correspondingly, each SMTP server will be associated with a pair of reference identifiers consisting of its hostname plus the next-hop domain "example.com".
SMTPサーバーmx1.example.comとmx2.example.comには、共通のトラストアンカーの下で証明書が発行されることが期待されますが、上記のCNAMEレコードにもかかわらず、各MXホスト名のTLSAベースドメインは変更されません。これに対応して、各SMTPサーバーは、そのホスト名とネクストホップドメイン "example.com"で構成される参照識別子のペアに関連付けられます。
If, during TLSA resolution (including possible CNAME indirection), at least one "secure" TLSA record is found (even if not usable because it is unsupported by the implementation or support is administratively disabled), then the corresponding host has signaled its commitment to implement TLS. The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS. This is required to avoid MITM STARTTLS downgrade attacks.
TLSA解決（可能なCNAMEインダイレクションを含む）中に、少なくとも1つの「安全な」TLSAレコードが見つかった場合（実装によってサポートされていないため、またはサポートが管理上無効になっているために使用できない場合でも）、対応するホストは、 TLSを実装します。 SMTPクライアントは、TLSセッションがSTARTTLS経由でネゴシエートされない限り、対応するホスト経由でメールを配信してはなりません（MUST NOT）。これは、MITM STARTTLSダウングレード攻撃を回避するために必要です。
As noted previously (in Section 2.2.2), when no "secure" TLSA records are found at the fully CNAME-expanded name, the original unexpanded name MUST be tried instead. This supports customers of hosting providers where the provider's zone cannot be validated with DNSSEC but the customer has shared appropriate key material with the hosting provider to enable TLS via SNI. Intermediate names that arise during CNAME expansion that are neither the original name nor the final name are never candidate TLSA base domains, even if "secure".
前述のように（セクション2.2.2）、完全にCNAMEで展開された名前に「安全な」TLSAレコードが見つからない場合は、元の展開されていない名前を代わりに試行する必要があります。これは、プロバイダーのゾーンをDNSSECで検証できないが、SNIを介してTLSを有効にするためにホスティングプロバイダーと適切なキーマテリアルを共有しているホスティングプロバイダーのお客様をサポートします。 「安全」であっても、CNAMEの展開中に元の名前でも最終名でもない中間名は、TLSA基本ドメインの候補にはなりません。
This section describes which TLSA records are applicable to SMTP opportunistic DANE TLS and how to apply such records to authenticate the SMTP server. With opportunistic DANE TLS, both the TLS support implied by the presence of DANE TLSA records and the verification parameters necessary to authenticate the TLS peer are obtained together. In contrast to protocols where channel security policy is set exclusively by the client, authentication via this protocol is expected to be less prone to connection failure caused by incompatible configuration of the client and server.
このセクションでは、SMTP日和見DANE TLSに適用できるTLSAレコードと、そのようなレコードを適用してSMTPサーバーを認証する方法について説明します。日和見DANE TLSでは、DANE TLSAレコードの存在によって暗示されるTLSサポートと、TLSピアの認証に必要な検証パラメーターの両方が同時に取得されます。チャネルセキュリティポリシーがクライアントによって排他的に設定されるプロトコルとは異なり、このプロトコルを介した認証は、クライアントとサーバーの構成に互換性がないために発生する接続障害の可能性が低くなると予想されます。
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types via combinations of three numeric parameters. The numeric values of these parameters were later given symbolic names in [RFC7218]. The rest of the TLSA record is the "certificate association data field", which specifies the full or digest value of a certificate or public key.
DANE TLSA仕様[RFC6698]は、3つの数値パラメーターの組み合わせを介して複数のTLSA RRタイプを定義しています。これらのパラメータの数値は後で[RFC7218]でシンボリック名を与えられました。 TLSAレコードの残りの部分は、「証明書関連付けデータフィールド」であり、証明書または公開鍵の完全な値またはダイジェスト値を指定します。
Since opportunistic DANE TLS will be used by non-interactive MTAs, with no user to "click OK" when authentication fails, reliability of peer authentication is paramount. Server operators are advised to publish TLSA records that are least likely to fail authentication due to interoperability or operational problems. Because DANE TLS relies on coordinated changes to DNS and SMTP server settings, the best choice of records to publish will depend on site-specific practices.
日和見的なDANE TLSは非インタラクティブMTAによって使用されるため、認証が失敗したときにユーザーが「OK」をクリックすることはないため、ピア認証の信頼性が最も重要です。サーバーオペレーターは、相互運用性または運用上の問題が原因で認証に失敗する可能性が最も低いTLSAレコードを公開することをお勧めします。 DANE TLSはDNSおよびSMTPサーバー設定の調整された変更に依存しているため、公開するレコードの最適な選択はサイト固有のプラクティスに依存します。
The certificate usage element of a TLSA record plays a critical role in determining how the corresponding certificate association data field is used to authenticate a server's certificate chain. Sections 3.1.1 and 3.1.2 explain the process for certificate usages DANE-EE(3) and DANE-TA(2), respectively. Section 3.1.3 briefly explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with opportunistic DANE TLS.
TLSAレコードの証明書使用法要素は、対応する証明書関連付けデータフィールドを使用してサーバーの証明書チェーンを認証する方法を決定する上で重要な役割を果たします。セクション3.1.1および3.1.2は、証明書の使用法DANE-EE（3）およびDANE-TA（2）のプロセスをそれぞれ説明しています。セクション3.1.3では、証明書の使用法PKIX-TA（0）およびPKIX-EE（1）が日和見DANE TLSに適用できない理由を簡単に説明しています。
In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second choice, depending on site needs. See Sections 3.1.1 and 3.1.2 for more details. Other combinations of TLSA parameters either (1) are explicitly unsupported or (2) offer little to recommend them over these two.
要約すると、「DANE-TA（2）Cert（0）SHA2-256（1）」TLSAレコードを使用して、「DANE-EE（3）SPKI（1）SHA2-256（1）」を使用することをお勧めします。サイトのニーズに応じて2番目の選択肢。詳細については、セクション3.1.1および3.1.2を参照してください。 TLSAパラメーターの他の組み合わせは、（1）明示的にサポートされていないか、（2）これらの2つよりも推奨するパラメーターがほとんどありません。
Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.
証明書の使用による認証DANE-EE（3）TLSAレコードは、サーバーのリーフ証明書がTLSAレコードと一致することを確認するだけです。特に、サーバーの公開鍵とその名前のバインドは、完全にTLSAレコードの関連付けに基づいています。証明書の名前がサーバーのクライアントの参照IDと一致しない場合でも、サーバーは認証済みであると見なされなければなりません（MUST）。
The expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature.
サーバー証明書の有効期限は無視する必要があります。TLSAレコードのキーバインディングの有効期間は、TLSAレコードのDNSSEC署名の有効期間によって決まります。
With DANE-EE(3), servers need not employ SNI (they may ignore the client's SNI message) even when the server is known under independent names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domains in question to match the server's default certificate. Of course, with SMTP servers it is simpler still to publish the same MX hostname for all the hosted domains.
DANE-EE（3）を使用すると、個別の証明書を必要とする独立した名前でサーバーが知られている場合でも、サーバーはSNIを使用する必要がありません（クライアントのSNIメッセージを無視できます）。代わりに、問題のすべてのドメインのTLSA RRsetがサーバーのデフォルトの証明書と一致することで十分です。もちろん、SMTPサーバーを使用すると、ホストされているすべてのドメインに同じMXホスト名を公開する方が簡単です。
For domains where it is practical to make coordinated changes in DNS TLSA records during SMTP server key rotation, it is often best to publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) certificates don't suddenly stop working when leaf or intermediate certificates expire, nor do they fail when the server operator neglects to configure all the required issuer certificates in the server certificate chain.
SMTPサーバーのキーローテーション中にDNS TLSAレコードを調整して変更することが実際的であるドメインの場合、エンドエンティティのDANE-EE（3）証明書の関連付けを公開するのが最善の方法です。 DANE-EE（3）証明書は、リーフまたは中間証明書の有効期限が切れても突然動作を停止せず、サーバーオペレーターがサーバー証明書チェーンで必要なすべての発行者証明書の構成を怠った場合でも失敗しません。
TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations are required to support SHA2-256, this record type works for all clients and need not change across certificate renewals with the same key.
SMTPサーバー用に公開されたTLSAレコードは、ほとんどの場合、「DANE-EE（3）SPKI（1）SHA2-256（1）」レコードである必要があります。すべてのDANE実装はSHA2-256をサポートする必要があるため、このレコードタイプはすべてのクライアントで機能し、同じキーを持つ証明書の更新全体で変更する必要はありません。
Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a trust anchor (TA) for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example:
一部のドメインは、TLSサービスごとに一意のTLSA RRを公開するという運用上の複雑さを回避することを好む場合があります。ドメインが共通の発行CAを使用して複数のTLSサービスの証明書を作成する場合、すべての関連サービスの証明書チェーンのトラストアンカー（TA）として発行機関を公開する方が簡単な場合があります。同じTAによって発行された各サービスのTLSAクエリドメイン（ポートとプロトコルのプレフィックスラベルが付いたTLSAベースドメイン）は、TAに一致する共通のTLSA RRsetを指すCNAMEエイリアスに設定できます。例えば：
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). The server MAY employ SNI to select the appropriate certificate to present to the client.
DANE-TA（2）を使用する場合、サーバー証明書には、クライアントの参照識別子の1つと一致する名前が必要です（[RFC6125]を参照）。サーバーは、SNIを使用して、クライアントに提示する適切な証明書を選択してもよい（MAY）。
SMTP servers that rely on certificate usage DANE-TA(2) TLSA records for TLS authentication MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message even when it is a self-signed root certificate. Many SMTP servers are not configured with a comprehensive list of trust anchors, nor are they expected to be at any point in the future. Some MTAs will ignore all locally trusted certificates when processing usage DANE-TA(2) TLSA records. Thus, even when the TA happens to be a public CA known to the SMTP client, authentication is likely to fail unless the TA certificate is included in the TLS server certificate message.
証明書の使用に依存するSMTPサーバーDANE-TA（2）TLS認証用のTLSAレコードは、自己署名ルート証明書であっても、TLSハンドシェイクサーバー証明書メッセージで提示される証明書チェーンの一部としてTA証明書を含める必要があります。多くのSMTPサーバーは、トラストアンカーの包括的なリストを使用して構成されておらず、将来のいずれかの時点で存在することも期待されていません。一部のMTAは、使用法DANE-TA（2）TLSAレコードを処理するときに、ローカルで信頼されている証明書をすべて無視します。したがって、TAがSMTPクライアントに既知のパブリックCAであっても、TAサーバー証明書がTLSサーバー証明書メッセージに含まれていない限り、認証は失敗する可能性があります。
With some SMTP server software, it is not possible to configure the server to include self-signed (root) CA certificates in the server certificate chain. Such servers either MUST publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE-EE(3) TLSA records.
一部のSMTPサーバーソフトウェアでは、サーバー証明書チェーンに自己署名（ルート）CA証明書を含めるようにサーバーを構成することができません。このようなサーバーは、中間証明書のDANE-TA（2）レコードを公開する必要があるか、代わりにDANE-EE（3）TLSAレコードを使用する必要があります。
TLSA records with a matching type of Full(0) are discouraged. While these potentially obviate the need to transmit the TA certificate in the TLS server certificate message, client implementations may not be able to augment the server certificate chain with the data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0) and avoid potential interoperability issues with large TLSA records containing full certificates or keys.
一致するタイプがFull（0）のTLSAレコードは推奨されません。これらにより、TLSサーバー証明書メッセージでTA証明書を送信する必要がなくなる可能性がありますが、クライアント実装では、特にTLSAレコードがベアキー（セレクターSPKI（ 1））。いずれの場合もサーバーはTA証明書を送信する必要があるため、サーバーオペレーターはFull（0）以外の一致するタイプでTLSAレコードを公開し、完全な証明書またはキーを含む大きなTLSAレコードとの潜在的な相互運用性の問題を回避する必要があります。
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. In particular, the SMTP client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints.
DANE-TA（2）レコードを使用するTLSAパブリッシャーは、Cert（0）のセレクターを使用してレコードをパブリッシュする必要があります（SHOULD）。このようなTLSAレコードは、トラストアンカー公開鍵だけでなく、トラストアンカー証明書全体に関連付けられています。特に、SMTPクライアントは、たとえば、パス長の制約など、トラストアンカー証明書からの関連する制約を適用する必要があります（SHOULD）。
While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full trust anchor certificate content, and elements of the trust anchor certificate other than the public key become mutable. This may, for example, allow a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.
SPKI（1）のセレクターも使用できますが、結果のTLSAレコードは完全なトラストアンカー証明書の内容を指定せず、公開鍵以外のトラストアンカー証明書の要素が変更可能になります。これにより、たとえば、子会社CAがトラストアンカーのパス長または名前の制約に違反するチェーンを発行できるようになります。
Note that this section applies to MTA-to-MTA SMTP, which is normally on port 25 -- that is, to servers that are the SMTP servers for one or more destination domains. Other uses of SMTP, such as in MUA-to-MSA submission on ports 587 or 465, are out of scope for this document. Where those other uses also employ TLS opportunistically and/or depend on DNSSEC as a result of DNS-based discovery of service location, the relevant specifications should, as appropriate, arrive at similar conclusions.
このセクションは、通常ポート25にあるMTA-to-MTA SMTPに適用されることに注意してください。つまり、1つ以上の宛先ドメインのSMTPサーバーであるサーバーに適用されます。ポート587または465でのMUAからMSAへの送信など、SMTPの他の使用法は、このドキュメントの範囲外です。これらの他の用途でも便宜的にTLSを採用している、および/またはサービスロケーションのDNSベースの検出の結果としてDNSSECに依存している場合、関連する仕様は、必要に応じて、同様の結論に到達する必要があります。
As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without relying on DNSSEC for "secure" MX records and DANE for STARTTLS support signaling, perform server identity verification or prevent STARTTLS downgrade attacks. The use of PKIX CAs offers no added security, since an attacker capable of compromising DNSSEC is free to replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient non-PKIX certificate usage. Finally, as explained in Section 1.3.4, there is no list of trusted CAs agreed upon by all MTAs and no user to "click OK" when a server's CA is not trusted by a client.
セクション1.3.1と1.3.2で述べたように、MTAの送信は、「セキュアな」MXレコードのDNSSECとSTARTTLSサポートシグナリングのDANEに依存せずに、サーバーID検証を実行するか、STARTTLSダウングレード攻撃を防ぐことができません。 DNSSECを危険にさらすことができる攻撃者はPKIX-TA（0）またはPKIX-EE（1）のTLSAレコードをPKIX以外の便利な証明書の使用法を含むレコードに自由に置き換えることができるため、PKIX CAを使用してもセキュリティは追加されません。最後に、セクション1.3.4で説明したように、すべてのMTAによって合意された信頼できるCAのリストはなく、サーバーのCAがクライアントによって信頼されていない場合、ユーザーは「OK」をクリックできません。
Therefore, TLSA records for the port 25 SMTP service used by client MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1). SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CAs. Lacking a complete set of public CAs, MTA clients would not be able to verify the certificates of SMTP servers whose issuing root CAs are not trusted by the client.
したがって、クライアントMTAが使用するポート25 SMTPサービスのTLSAレコードには、証明書の使用方法がPKIX-TA（0）またはPKIX-EE（1）のTLSA RRを含めるべきではありません（SHOULD NOT）。 SMTPクライアントMTAは、信頼できるパブリックCAの完全に適切なセットで構成することはできません。パブリックCAの完全なセットがないと、MTAクライアントは、発行ルートCAがクライアントによって信頼されていないSMTPサーバーの証明書を検証できません。
Opportunistic DANE TLS needs to interoperate without bilateral coordination of security settings between client and server systems. Therefore, parameter choices that are fragile in the absence of bilateral coordination are unsupported. Nothing is lost; since the PKIX certificate usages cannot aid SMTP TLS security, they can only impede SMTP TLS interoperability.
Opportunistic DANE TLSは、クライアントシステムとサーバーシステム間のセキュリティ設定を相互に調整することなく相互運用する必要があります。したがって、二国間の調整がない場合に壊れやすいパラメーターの選択はサポートされません。何も失われません。 PKIX証明書の使用はSMTP TLSセキュリティを支援できないため、SMTP TLSの相互運用性を妨げるだけです。
SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other unsupported certificate usage, SMTP clients MAY treat such records as "unusable".
証明書の使用法がPKIX-TA（0）またはPKIX-EE（1）のTLSA RRのSMTPクライアント処理は定義されていません。他のサポートされていない証明書の使用と同様に、SMTPクライアントはそのようなレコードを「使用不可」として扱うことができます（MAY）。
When at least one usable "secure" TLSA record is found, the SMTP client MUST use TLSA records to authenticate the SMTP server. Messages MUST NOT be delivered via the SMTP server if authentication fails; otherwise, the SMTP client is vulnerable to MITM attacks.
少なくとも1つの使用可能な「安全な」TLSAレコードが見つかった場合、SMTPクライアントはTLSAレコードを使用してSMTPサーバーを認証する必要があります。認証が失敗した場合、メッセージはSMTPサーバーを介して配信してはなりません（MUST NOT）。それ以外の場合、SMTPクライアントはMITM攻撃に対して脆弱です。
The SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3) (Section 3.1.1).
SMTPクライアントは、証明書の使用法DANE-EE（3）（セクション3.1.1）で証明書名のチェックを実行してはなりません（MUST NOT）。
To match a server via a TLSA record with certificate usage DANE-TA(2), the client MUST perform name checks to ensure that it has reached the correct server. In all DANE-TA(2) cases, the SMTP client MUST employ the TLSA base domain as the primary reference identifier for matching the server certificate.
TLSAレコードを介してサーバーを証明書の使用法DANE-TA（2）と照合するには、クライアントは名前チェックを実行して、サーバーが正しいサーバーに到達したことを確認する必要があります。すべてのDANE-TA（2）の場合、SMTPクライアントは、サーバー証明書を照合するためのプライマリ参照識別子としてTLSAベースドメインを使用する必要があります。
TLSA records for MX hostnames: If the TLSA base domain was obtained indirectly via a "secure" MX lookup (including any CNAME-expanded name of an MX hostname), then the original next-hop domain used in the MX lookup MUST be included as a second reference identifier. The CNAME-expanded original next-hop domain MUST be included as a third reference identifier if different from the original next-hop domain. When the client MTA is employing DANE TLS security despite "insecure" MX redirection, the MX hostname is the only reference identifier.
MXホスト名のTLSAレコード：TLSA基本ドメインが「安全な」MXルックアップ（MXホスト名のCNAME展開名を含む）を介して間接的に取得された場合、MXルックアップで使用される元のネクストホップドメインを次のように含める必要があります。 2番目の参照識別子。 CNAMEで拡張された元のネクストホップドメインは、元のネクストホップドメインと異なる場合、3番目の参照識別子として含める必要があります。 「安全でない」MXリダイレクションにもかかわらず、クライアントMTAがDANE TLSセキュリティを採用している場合、MXホスト名が唯一の参照識別子です。
TLSA records for non-MX hostnames: If MX records were not used (e.g., if none exist) and the TLSA base domain is the CNAME-expanded original next-hop domain, then the original next-hop domain MUST be included as a second reference identifier.
非MXホスト名のTLSAレコード：MXレコードが使用されなかった場合（たとえば、存在しない場合）、TLSAベースドメインがCNAMEで拡張された元のネクストホップドメインである場合、元のネクストホップドメインを2番目として含める必要があります。参照識別子。
Accepting certificates with the original next-hop domain in addition to the MX hostname allows a domain with multiple MX hostnames to field a single certificate bearing a single domain name (i.e., the email domain) across all the SMTP servers. This also aids interoperability with pre-DANE SMTP clients that are configured to look for the email domain name in server certificates -- for example, with "secure" DNS records as shown below:
MXホスト名に加えて元のネクストホップドメインで証明書を受け入れると、複数のMXホスト名を持つドメインが、すべてのSMTPサーバーにわたって単一のドメイン名（つまり、電子メールドメイン）を持つ単一の証明書をフィールド化できます。これは、サーバー証明書で電子メールドメイン名を検索するように構成されたDANE以前のSMTPクライアントとの相互運用性も支援します。たとえば、以下に示す「安全な」DNSレコードを使用します。
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
example.com. IN MX 15 mx15.example.com.
example.com. IN MX 20 mx20.example.com.
;
mx10.example.com. IN A 192.0.2.10
_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
;
mx15.example.com. IN CNAME mxbackup.example.com.
mxbackup.example.com. IN A 192.0.2.15
; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
;
mx20.example.com. IN CNAME mxbackup.example.net.
mxbackup.example.net. IN A 198.51.100.20
_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
Certificate name checks for delivery of mail to exchange.example.org via any of the associated SMTP servers MUST accept at least the names "exchange.example.org" and "example.com", which are, respectively, the original and fully expanded next-hop domain. When the SMTP server is mx10.example.com, name checks MUST accept the TLSA base domain "mx10.example.com". If, despite the fact that MX hostnames are required to not be aliases, the MTA supports delivery via "mx15.example.com" or "mx20.example.com", then name checks MUST accept the respective TLSA base domains "mx15.example.com" and "mxbackup.example.net".
関連付けられたSMTPサーバーのいずれかを介したexchange.example.orgへのメール配信の証明書名チェックは、少なくとも「exchange.example.org」と「example.com」の名前をそれぞれ受け入れる必要がありますネクストホップドメイン。 SMTPサーバーがmx10.example.comの場合、名前のチェックはTLSAベースドメイン「mx10.example.com」を受け入れる必要があります。 MXホスト名がエイリアスではないことが要求されるという事実にもかかわらず、MTAが「mx15.example.com」または「mx20.example.com」を介した配信をサポートする場合、名前のチェックはそれぞれのTLSAベースドメイン「mx15.example」を受け入れる必要があります.com」および「mxbackup.example.net」。
When name checks are applicable (certificate usage DANE-TA(2)), if the server certificate contains a Subject Alternative Name extension [RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs are matched against the client's reference identifiers. The CN-ID [RFC6125] is only considered when no DNS-IDs are present. The server certificate is considered matched when one of its presented identifiers [RFC5280] matches any of the client's reference identifiers.
名前チェックが適用される場合（証明書の使用法DANE-TA（2））、サーバー証明書に少なくとも1つのDNS-ID [RFC6125]を持つサブジェクト代替名拡張[RFC5280]が含まれている場合、DNS-IDのみがクライアントの参照識別子。 CN-ID [RFC6125]は、DNS-IDが存在しない場合にのみ考慮されます。提示された識別子の1つ[RFC5280]がクライアントの参照識別子のいずれかに一致する場合、サーバー証明書は一致したと見なされます。
Wildcards are valid in either DNS-IDs or the CN-ID when applicable. The wildcard character must be the entire first label of the DNS-ID or CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and "*smtp.example.com" are not. SMTP clients MUST support wildcards that match the first label of the reference identifier, with the remaining labels matching verbatim. For example, the DNS-ID "*.example.com" matches the reference identifier "mx1.example.com". SMTP clients MAY, subject to local policy, allow wildcards to match multiple reference identifier labels, but servers cannot expect broad support for such a policy. Therefore, any wildcards in server certificates SHOULD match exactly one label in either the TLSA base domain or the next-hop domain.
ワイルドカードは、該当する場合、DNS-IDまたはCN-IDで有効です。ワイルドカード文字は、DNS-IDまたはCN-IDの最初のラベル全体である必要があります。したがって、「*。example.com」は有効ですが、「smtp * .example.com」と「* smtp.example.com」は無効です。 SMTPクライアントは、参照識別子の最初のラベルに一致するワイルドカードをサポートする必要があり、残りのラベルは逐語的に一致します。たとえば、DNS-ID「*。example.com」は参照識別子「mx1.example.com」と一致します。 SMTPクライアントは、ローカルポリシーに従って、ワイルドカードが複数の参照識別子ラベルと一致することを許可する場合がありますが、サーバーはそのようなポリシーの幅広いサポートを期待できません。したがって、サーバー証明書内のワイルドカードは、TLSAベースドメインまたはネクストホップドメインのいずれか1つのラベルと正確に一致する必要があります（SHOULD）。
Two TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and the other matching the new key scheduled to replace it. Once sufficient time has elapsed for all DNS caches to expire the previous TLSA RRset and related signature RRsets, servers may be configured to use the new EE private key and associated public key certificate or may employ certificates signed by the new trust anchor.
新しいEEまたはTA公開鍵または証明書を使用する前に、2つのTLSAレコードを公開する必要があります。1つは現在デプロイされている鍵と一致し、もう1つはそれを置き換える予定の新しい鍵と一致します。すべてのDNSキャッシュが以前のTLSA RRsetおよび関連する署名RRsetを期限切れにするのに十分な時間が経過すると、サーバーは、新しいEE秘密キーと関連する公開キー証明書を使用するように構成するか、または新しいトラストアンカーによって署名された証明書を使用できます。
Once the new public key or certificate is in use, the TLSA RR that matches the retired key can be removed from DNS, leaving only RRs that match keys or certificates in active use.
新しい公開鍵または証明書が使用されると、廃止された鍵と一致するTLSA RRをDNSから削除し、アクティブに使用されている鍵または証明書と一致するRRのみを残すことができます。
As described in Section 3.1.2, when server certificates are validated via a DANE-TA(2) trust anchor and CNAME records are employed to store the TA association data at a single location, the responsibility of updating the TLSA RRset shifts to the operator of the trust anchor. Before a new trust anchor is used to sign any new server certificates, its certificate (digest) is added to the relevant TLSA RRset. After enough time elapses for the original TLSA RRset to age out of DNS caches, the new trust anchor can start issuing new server certificates. Once all certificates issued under the previous trust anchor have expired, its associated RRs can be removed from the TLSA RRset.
セクション3.1.2で説明されているように、サーバー証明書がDANE-TA（2）トラストアンカーを介して検証され、CNAMEレコードが単一の場所にTAアソシエーションデータを格納するために使用される場合、TLSA RRsetを更新する責任はオペレーターに移りますトラストアンカーの。新しいトラストアンカーを使用して新しいサーバー証明書に署名する前に、その証明書（ダイジェスト）が関連するTLSA RRsetに追加されます。元のTLSA RRsetがDNSキャッシュを期限切れにするのに十分な時間が経過すると、新しいトラストアンカーは新しいサーバー証明書の発行を開始できます。以前のトラストアンカーの下で発行されたすべての証明書の有効期限が切れると、それに関連付けられたRRをTLSA RRsetから削除できます。
In the DANE-TA(2) key management model, server operators do not generally need to update DNS TLSA records after initially creating a CNAME record that references the centrally operated DANE-TA(2) RRset. If a particular server's key is compromised, its TLSA CNAME SHOULD be replaced with a DANE-EE(3) association until the certificate for the compromised key expires, at which point it can return to using a CNAME record. If the central trust anchor is compromised, all servers need to be issued new keys by a new TA, and an updated DANE-TA(2) TLSA RRset needs to be published containing just the new TA.
DANE-TA（2）鍵管理モデルでは、サーバーオペレーターは通常、中央で動作するDANE-TA（2）RRsetを参照するCNAMEレコードを最初に作成した後、DNS TLSAレコードを更新する必要はありません。特定のサーバーのキーが侵害された場合、そのTLSA CNAMEは、侵害されたキーの証明書の有効期限が切れるまでDANE-EE（3）アソシエーションで置き換える必要があります（SHOULD）。この時点で、CNAMEレコードの使用に戻ることができます。中央のトラストアンカーが危険にさらされている場合、すべてのサーバーは新しいTAによって新しいキーを発行される必要があり、更新されたDANE-TA（2）TLSA RRsetは新しいTAのみを含むように公開される必要があります。
SMTP servers cannot expect broad Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) support from SMTP clients. As outlined above, with DANE, compromised server or trust anchor keys can be "revoked" by removing them from the DNS without the need for client-side support for OCSP or CRLs.
SMTPサーバーは、SMTPクライアントからの広範な証明書失効リスト（CRL）またはオンライン証明書ステータスプロトコル（OCSP）のサポートを期待できません。上で概説したように、DANEを使用すると、クライアント側でOCSPまたはCRLをサポートする必要なく、DNSからそれらを削除することにより、侵害されたサーバーまたはトラストアンカーキーを「取り消す」ことができます。
While [RFC6698] specifies multiple digest algorithms, it does not specify a protocol by which the SMTP client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol would allow the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients. When stronger algorithms are an option, deprecated algorithms SHOULD be avoided. Such a protocol is specified in [RFC7671]. SMTP clients and servers that implement this specification MUST comply with the requirements outlined in Section 9 of [RFC7671].
[RFC6698]は複数のダイジェストアルゴリズムを指定していますが、SMTPクライアントとTLSAレコードパブリッシャーが最も強力な共有アルゴリズムに同意できるプロトコルを指定していません。このようなプロトコルにより、クライアントとサーバーは、能力の低いクライアントとの互換性のために公開されている非推奨の弱いアルゴリズムにさらされることを回避できます。より強力なアルゴリズムがオプションである場合、廃止されたアルゴリズムは避けられるべきです。そのようなプロトコルは[RFC7671]で指定されています。この仕様を実装するSMTPクライアントとサーバーは、[RFC7671]のセクション9で概説されている要件に準拠する必要があります。
An MTA implementing this protocol may require a stronger security assurance when sending email to selected destinations. The sending organization may need to send sensitive email and/or may have regulatory obligations to protect its content. This protocol is not in conflict with such a requirement and, in fact, can often simplify authenticated delivery to such destinations.
このプロトコルを実装するMTAでは、選択した宛先に電子メールを送信するときに、より強力なセキュリティ保証が必要になる場合があります。送信側の組織は、機密性の高いメールを送信する必要がある場合や、コンテンツを保護するための規制上の義務がある場合があります。このプロトコルは、このような要件と競合しておらず、実際、多くの場合、このような宛先への認証済み配信を単純化できます。
Specifically, with domains that publish DANE TLSA records for their MX hostnames, a sending MTA can be configured to use the receiving domain's DANE TLSA records to authenticate the corresponding SMTP server. Authentication via DANE TLSA records is easier to manage, as changes in the receiver's expected certificate properties are made on the receiver end and don't require manually communicated configuration changes. With mandatory DANE TLS, when no usable TLSA records are found, message delivery is delayed. Thus, mail is only sent when an authenticated TLS channel is established to the remote SMTP server.
具体的には、MXホスト名のDANE TLSAレコードを公開するドメインでは、受信側ドメインのDANE TLSAレコードを使用して対応するSMTPサーバーを認証するように送信MTAを構成できます。 DANE TLSAレコードを介した認証は、受信側で期待される証明書のプロパティの変更が受信側で行われ、手動で伝達される構成変更を必要としないため、管理がより簡単です。必須のDANE TLSでは、使用可能なTLSAレコードが見つからない場合、メッセージの配信が遅延します。したがって、メールは、認証されたTLSチャネルがリモートSMTPサーバーに確立されたときにのみ送信されます。
Administrators of mail servers that employ mandatory DANE TLS need to carefully monitor their mail logs and queues. If a partner domain unwittingly misconfigures its TLSA records, disables DNSSEC, or misconfigures SMTP server certificate chains, mail will be delayed and may bounce if the issue is not resolved in a timely manner.
必須のDANE TLSを採用しているメールサーバーの管理者は、メールログとキューを注意深く監視する必要があります。パートナードメインがTLSAレコードを誤って構成したり、DNSSECを無効にしたり、SMTPサーバー証明書チェーンを誤って構成したりすると、メールが遅延し、問題がタイムリーに解決されないとバウンスする可能性があります。
We note that SMTP is also used between Message User Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In [RFC6186], a protocol is specified that enables an MUA to dynamically locate the MSA based on the user's email address. SMTP connection security considerations for MUAs implementing [RFC6186] are largely analogous to connection security requirements for MTAs, and this specification could be applied largely verbatim with DNS MX records replaced by corresponding DNS Service (SRV) records [RFC7673].
SMTPは、メッセージユーザーエージェント（MUA）とメッセージ送信エージェント（MSA）[RFC6409]の間でも使用されることに注意してください。 [RFC6186]では、MUAがユーザーの電子メールアドレスに基づいてMSAを動的に特定できるようにするプロトコルが指定されています。 [RFC6186]を実装するMUAのSMTP接続セキュリティの考慮事項は、MTAの接続セキュリティ要件にほぼ類似しており、この仕様は、対応するDNSサービス（SRV）レコード[RFC7673]に置き換えられたDNS MXレコードとほぼそのまま適用できます。
However, until MUAs begin to adopt the dynamic configuration mechanisms of [RFC6186], they are adequately served by more traditional static TLS security policies. Specification of DANE TLS for MUA-to-MSA SMTP is left to future documents that focus specifically on SMTP security between MUAs and MSAs.
ただし、MUAが[RFC6186]の動的構成メカニズムを採用し始めるまで、それらはより伝統的な静的TLSセキュリティポリシーによって適切に処理されます。 MUA-to-MSA SMTPのDANE TLSの仕様は、MUAとMSA間のSMTPセキュリティに特に焦点を当てた将来のドキュメントに委ねられています。
To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain. This precludes the use of the Secure Socket Layer (SSL) HELLO that is SSL 2.0 compatible by the SMTP client.
サーバーが正しい証明書チェーンを送信することを保証するために、SMTPクライアントは、TLSA基本ドメインを含むTLS SNI拡張を送信する必要があります。これにより、SMTPクライアントによるSSL 2.0互換のSecure Socket Layer（SSL）HELLOを使用できなくなります。
Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records. The server MAY rely on SNI to determine which certificate chain to present to the client. Clients that don't send SNI information may not see the expected certificate chain.
各SMTPサーバーは、少なくとも1つのTLSAレコードと一致する証明書チェーン（[RFC5246]、セクション7.4.2を参照）を提示する必要があります。サーバーは、クライアントに提示する証明書チェーンを決定するためにSNIに依存してもよい（MAY）。 SNI情報を送信しないクライアントは、期待される証明書チェーンを表示しない場合があります。
If the server's TLSA records match the server's default certificate chain, the server need not support SNI. In either case, the server need not include the SNI extension in its TLS HELLO, as simply returning a matching certificate chain is sufficient. Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server. If the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that DANE TLS clients are typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name acceptable to the client, e.g., the original next-hop domain.
サーバーのTLSAレコードがサーバーのデフォルトの証明書チェーンと一致する場合、サーバーはSNIをサポートする必要はありません。どちらの場合も、一致する証明書チェーンを返すだけで十分なので、サーバーはTLS HELLOにSNI拡張を含める必要はありません。クライアントは認証されていない便宜的なTLSを使用している可能性があり、サーバーからの特定の証明書を期待できないため、サーバーはクライアントによるSNIの使用を強制してはなりません。クライアントがSNI拡張を送信しない場合、またはサポートされていないドメインのSNI拡張を送信する場合、サーバーは単に選択したフォールバック証明書チェーンを送信する必要があります。要求されたSNIホスト名の厳密な一致を強制しない理由は、DANE TLSクライアントは通常、複数のサーバー名を受け入れても、SNI拡張で1つの名前しか送信できないためです。サーバーのフォールバック証明書は、元のネクストホップドメインなど、クライアントが受け入れ可能な別の名前と一致する場合があります。
Since many SMTP servers either do not support or do not enable any anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD offer to negotiate a typical set of non-anonymous cipher suites required for interoperability with such servers. An SMTP client employing pre-DANE opportunistic TLS MAY also include one or more anonymous TLS cipher suites in its TLS HELLO. SMTP servers that need to interoperate with opportunistic TLS clients SHOULD be prepared to interoperate with such clients by either always selecting a mutually supported non-anonymous cipher suite or correctly handling client connections that negotiate anonymous cipher suites.
多くのSMTPサーバーは匿名のTLS暗号スイートをサポートしていないか、有効にしていないため、SMTPクライアントのTLS HELLOメッセージは、そのようなサーバーとの相互運用に必要な非匿名の暗号スイートの典型的なセットをネゴシエートすることを提案する必要があります。 DANE以前の便宜的なTLSを採用しているSMTPクライアントは、そのTLS HELLOに1つ以上の匿名TLS暗号スイートを含めることもできます（MAY）。便宜的TLSクライアントと相互運用する必要があるSMTPサーバーは、相互にサポートされる非匿名暗号スイートを常に選択するか、匿名暗号スイートをネゴシエートするクライアント接続を正しく処理することにより、そのようなクライアントと相互運用できるように準備する必要があります。
Note that while SMTP server operators are under no obligation to enable anonymous cipher suites, no security is gained by sending certificates to clients that will ignore them. Indeed, support for anonymous cipher suites in the server makes audit trails more informative. Log entries that record connections that employed an anonymous cipher suite record the fact that the clients did not care to authenticate the server.
SMTPサーバーのオペレーターは匿名の暗号スイートを有効にする義務はありませんが、それらを無視するクライアントに証明書を送信してもセキュリティは得られないことに注意してください。実際、サーバーでの匿名暗号スイートのサポートにより、監査証跡がより有益になります。匿名の暗号スイートを採用した接続を記録するログエントリは、クライアントがサーバーを認証することを気にしなかったという事実を記録します。
An operational error on the sending or receiving side that cannot be corrected in a timely manner may, at times, lead to consistent failure to deliver time-sensitive email. The sending MTA administrator may have to choose between allowing email to queue until the error is resolved and disabling opportunistic or mandatory DANE TLS (Section 6) for one or more destinations. The choice to disable DANE TLS security should not be made lightly. Every reasonable effort should be made to determine that problems with mail delivery are the result of an operational error and not an attack. A fallback strategy may be to configure explicit out-of-band TLS security settings if supported by the sending MTA.
送信側または受信側の操作エラーがタイムリーに修正できない場合、時宜にかなったメールの配信に常に失敗することがあります。送信側のMTA管理者は、エラーが解決されるまで電子メールをキューに入れることを許可するか、1つ以上の宛先の便宜的または必須のDANE TLS（セクション6）を無効にするかを選択する必要があります。 DANE TLSセキュリティを無効にする選択は、軽視すべきではありません。メール配信の問題が操作エラーの結果であり、攻撃ではないことを確認するために、あらゆる合理的な努力が必要です。フォールバック戦略は、送信側MTAでサポートされている場合、明示的な帯域外TLSセキュリティ設定を構成することです。
SMTP clients may deploy opportunistic DANE TLS incrementally by enabling it only for selected sites or may occasionally need to disable opportunistic DANE TLS for peers that fail to interoperate due to misconfiguration or software defects on either end. Some implementations MAY support DANE TLS in an "audit only" mode in which failure to achieve the requisite security level is logged as a warning and delivery proceeds at a reduced security level. Unless local policy specifies "audit only" or specifies that opportunistic DANE TLS is not to be used for a particular destination, an SMTP client MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server.
SMTPクライアントは、選択されたサイトに対してのみ有効にすることにより、便宜的DANE TLSを段階的に導入するか、またはいずれかの側の設定ミスまたはソフトウェアの欠陥が原因で相互運用に失敗したピアの便宜的DANE TLSを無効にする必要がある場合があります。一部の実装は、「監査のみ」モードでDANE TLSをサポートする場合があります。このモードでは、必要なセキュリティレベルを達成できなかった場合に警告としてログに記録され、セキュリティレベルが低下して配信が続行されます。ローカルポリシーで「監査のみ」が指定されているか、特定の宛先に便宜的なDANE TLSが使用されていないことを指定していない限り、SMTPクライアントは、使用可能なTLSAレコードがある場合に、証明書チェーンが少なくとも1つのTLSAレコードと一致しないサーバーを介してメールを配信してはならない（MUST NOT）そのサーバーで見つかりました。
Some MTAs enable STARTTLS selectively. For example, they might only support STARTTLS with clients that have previously demonstrated "proper MTA behavior", e.g., by retrying the delivery of deferred messages (greylisting). If such an MTA publishes DANE TLSA records, sending MTAs that implement this specification will not attempt the initial cleartext SMTP transaction needed to establish the "proper MTA behavior", because they cannot establish the required channel security. Server operators MUST NOT implement selective STARTTLS if they also want to support DANE TLSA.
一部のMTAは、STARTTLSを選択的に有効にします。たとえば、遅延メッセージの配信を再試行するなどして、以前に「適切なMTA動作」を示したクライアントでのみSTARTTLSをサポートする場合があります（グレーリスト）。そのようなMTAがDANE TLSAレコードを公開する場合、この仕様を実装するMTAを送信しても、必要なチャネルセキュリティを確立できないため、「適切なMTA動作」を確立するために必要な初期クリアテキストSMTPトランザクションは試行されません。サーバーオペレーターは、DANE TLSAもサポートする場合は、選択的STARTTLSを実装してはなりません（MUST NOT）。
TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].
TLSAパブリッシャーは、[RFC7671]のセクション8のガイドラインに従う必要があります。
TLSA Publishers SHOULD follow the TLSA publication size guidance found in Section 10.1 of [RFC7671].
TLSAパブリッシャーは、[RFC7671]のセクション10.1にあるTLSAパブリケーションサイズのガイダンスに従う必要があります。
TLSA Publishers SHOULD follow the TLSA record TTL and signature lifetime recommendations found in Section 13 of [RFC7671].
TLSAパブリッシャーは、[RFC7671]のセクション13にあるTLSAレコードのTTLと署名の有効期間に関する推奨事項に従う必要があります。
This protocol leverages DANE TLSA records to implement MITM-resistant Opportunistic Security [RFC7435] for SMTP. For destination domains that sign their MX records and publish signed TLSA records for their MX hostnames, this protocol allows sending MTAs to securely discover both the availability of TLS and how to authenticate the destination.
このプロトコルは、DANE TLSAレコードを利用して、SMTPに対してMITM耐性のOpportunistic Security [RFC7435]を実装します。 MXレコードに署名し、MXホスト名の署名済みTLSAレコードを公開する宛先ドメインの場合、このプロトコルにより、送信MTAはTLSの可用性と宛先の認証方法の両方を安全に検出できます。
This protocol does not aim to secure all SMTP traffic, as that is not practical until DNSSEC and DANE adoption are universal. The incremental deployment provided by following this specification is a best possible path for securing SMTP. This protocol coexists and interoperates with the existing insecure Internet email backbone.
このプロトコルは、すべてのSMTPトラフィックを保護することを目的としていません。DNSSECとDANEの採用が普遍的になるまで、これは実用的ではないからです。この仕様に従うことで提供される増分展開は、SMTPを保護するための最良の方法です。このプロトコルは、既存の安全でないインターネット電子メールバックボーンと共存および相互運用します。
The protocol does not preclude existing non-opportunistic SMTP TLS security arrangements, which can continue to be used as before via manual configuration with negotiated out-of-band key and TLS configuration exchanges.
このプロトコルは、既存の非便宜的なSMTP TLSセキュリティ構成を排除しません。これは、交渉された帯域外キーとTLS構成の交換による手動構成を介して以前と同様に引き続き使用できます。
Opportunistic SMTP TLS depends critically on DNSSEC for downgrade resistance and secure resolution of the destination name. If DNSSEC is compromised, it is not possible to fall back on the public CA PKI to prevent MITM attacks. A successful breach of DNSSEC enables the attacker to publish TLSA usage 3 certificate associations and thereby bypass any security benefit the legitimate domain owner might hope to gain by publishing usage 0 or usage 1 TLSA RRs. Given the lack of public CA PKI support in existing MTA deployments, avoiding certificate usages 0 and 1 simplifies implementation and deployment with no adverse security consequences.
Opportunistic SMTP TLSは、ダウングレード耐性と宛先名の安全な解決のためにDNSSECに大きく依存しています。 DNSSECが侵害された場合、パブリックCA PKIにフォールバックしてMITM攻撃を防ぐことはできません。 DNSSECの違反が成功すると、攻撃者はTLSA使用法3の証明書の関連付けを公開できるため、正当なドメイン所有者が使用法0または使用法1のTLSA RRを公開することで期待できるセキュリティ上の利点を回避できます。既存のMTA展開にパブリックCA PKIサポートがないため、証明書の使用0と1を回避すると、セキュリティに悪影響を与えることなく、実装と展開が簡略化されます。
Implementations must strictly follow Sections 2.1.2, 2.1.3, 2.2, 2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1 of this specification; these sections indicate when it is appropriate to initiate a non-authenticated connection or cleartext connection to an SMTP server. Specifically, in order to prevent downgrade attacks on this protocol, implementations must not initiate a connection when this specification indicates that a particular SMTP server must be considered unreachable.
実装は、この仕様のセクション2.1.2、2.1.3、2.2、2.2.1、2.2.2、2.2.3、3.2、および9.1に厳密に従う必要があります。これらのセクションは、SMTPサーバーへの非認証接続またはクリアテキスト接続を開始することが適切な場合を示しています。具体的には、このプロトコルへのダウングレード攻撃を防ぐために、特定のSMTPサーバーが到達不能と見なされなければならないことがこの仕様で示されている場合、実装は接続を開始してはなりません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<http://www.rfc-editor.org/info/rfc3207>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< http://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< http://www.rfc-editor.org/info/rfc4035>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<http://www.rfc-editor.org/info/rfc5598>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<http://www.rfc-editor.org/info/rfc6066> 。
[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, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <http://www.rfc-editor.org/info/rfc6186>.
[RFC6186] Daboo、C。、「電子メールの送信/アクセスサービスを見つけるためのSRVレコードの使用」、RFC 6186、DOI 10.17487 / RFC6186、2011年3月、<http://www.rfc-editor.org/info/rfc6186> 。
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672] Rose、S。およびW. Wijngaards、「DNAME Redirection in the DNS」、RFC 6672、DOI 10.17487 / RFC6672、2012年6月、<http://www.rfc-editor.org/info/rfc6672>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<http：/ /www.rfc-editor.org/info/rfc6698>。
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218] Gudmundsson、O。、「名前付きエンティティのDNSベースの認証（DANE）に関する会話を簡素化するための頭字語の追加」、RFC 7218、DOI 10.17487 / RFC7218、2014年4月、<http://www.rfc-editor.org / info / rfc7218>。
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.
[RFC7671] Dukhovni、V。およびW. Hardaker、「DNSベースの名前付きエンティティの認証（DANE）プロトコル：更新と運用ガイダンス」、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<http：// www。 rfc-editor.org/info/rfc7671>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメインネームシステムの動的更新（DNS UPDATE）」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月、<http://www.rfc-editor.org/info/rfc2136>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<http://www.rfc-editor.org/info/rfc2181>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.
[RFC6409] Gellens、R。およびJ. Klensin、「メールのメッセージ送信」、STD 72、RFC 6409、DOI 10.17487 / RFC6409、2011年11月、<http://www.rfc-editor.org/info/rfc6409> 。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673] Finch、T.、Miller、M。、およびP. Saint-Andre、「DNSベースの名前付きエンティティの認証（DANE）TLSAレコードとSRVレコードの使用」、RFC 7673、DOI 10.17487 / RFC7673、2015年10月、 <http://www.rfc-editor.org/info/rfc7673>。
Acknowledgements
謝辞
The authors would like to extend great thanks to Tony Finch, who started the original version of a DANE SMTP document. His work is greatly appreciated and has been incorporated into this document. The authors would like to additionally thank Phil Pennock for his comments and advice on this document.
著者は、DANE SMTPドキュメントのオリジナルバージョンを開始したTony Finchに深く感謝します。彼の仕事は高く評価され、このドキュメントに組み込まれています。著者は、このドキュメントに関する彼のコメントとアドバイスをしてくれたPhil Pennockにさらに感謝したいと思います。
Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated me to begin work on this memo and provided feedback on early draft versions of this document. Thanks to Patrick Koetter, Perry Metzger, and Nico Williams for valuable review comments. Thanks also to Wietse Venema, who created Postfix, and whose advice and feedback were essential to the development of the Postfix DANE implementation.
Viktorからの謝辞：このメモに取り掛かる動機を与え、このドキュメントの初期のドラフトバージョンにフィードバックを提供してくれたPaul Hoffmanに感謝します。貴重なレビューコメントを提供してくれたPatrick Koetter、Perry Metzger、Nico Williamsに感謝します。 Postfixを作成したWietse Venemaにも感謝します。そのアドバイスとフィードバックはPostfix DANE実装の開発に不可欠でした。
Authors' Addresses
著者のアドレス
Viktor Dukhovni Two Sigma
ビクタースピリチュアルツーシグマ
Email: ietf-dane@dukhovni.org
Wes Hardaker Parsons P.O. Box 382 Davis, CA 95617 United States
うぇｓ はｒだけｒ ぱｒそんｓ Ｐ。お。 ぼｘ ３８２ だゔぃｓ、 か ９５６１７ うにてｄ Ｓたてｓ
Email: ietf@hardakers.net