RFC 8624 - Algorithm Implementation Requirements and Usage Guidance for DNSSEC 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8624
タイトル : RFC 8624 - DNSSECのアルゴリズム実装要件と使用ガイダンス
翻訳編集 : 自動生成

[要約] RFC 8624は、DNSSECのアルゴリズム実装要件と使用ガイダンスに関するものであり、DNSセキュリティ拡張の実装に関する指針を提供する。目的は、DNSSECのアルゴリズムの選択と実装に関する一貫性と互換性を確保することである。

Internet Engineering Task Force (IETF)                        P. Wouters
Request for Comments: 8624                                       Red Hat
Obsoletes: 6944                                                  O. Sury
Category: Standards Track                    Internet Systems Consortium
ISSN: 2070-1721                                                June 2019

Algorithm Implementation Requirements and Usage Guidance for DNSSEC

DNSSECのアルゴリズム実装要件と使用ガイダンス

Abstract

概要

The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.

DNSSECプロトコルは、DNSデータの認証と存在しないことの証明を提供するために、さまざまな暗号化アルゴリズムを利用しています。 DNSリゾルバーとDNS権威サーバー間の相互運用性を確保するには、一連のアルゴリズム実装要件と使用ガイドラインを指定して、すべての実装がサポートするアルゴリズムが少なくとも1つあることを確認する必要があります。このドキュメントでは、DNSSECの現在のアルゴリズム実装要件と使用法のガイダンスを定義します。このドキュメントはRFC 6944を廃止します。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8624.

このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8624で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Updating Algorithm Implementation Requirements and Usage
           Guidance  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Updating Algorithm Requirement Levels . . . . . . . . . .   3
     1.3.  Document Audience . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Algorithm Selection . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . .   5
     3.2.  DNSKEY Algorithm Recommendation . . . . . . . . . . . . .   6
     3.3.  DS and CDS Algorithms . . . . . . . . . . . . . . . . . .   7
     3.4.  DS and CDS Algorithm Recommendation . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

The DNSSEC signing algorithms are defined by various RFCs, including [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080]. DNSSEC is used to provide authentication of data. To ensure interoperability, a set of "mandatory-to-implement" DNSKEY algorithms are defined. This document obsoletes [RFC6944].

DNSSEC署名アルゴリズムは、[RFC4034]、[RFC5155]、[RFC5702]、[RFC5933]、[RFC6605]、[RFC8080]など、さまざまなRFCによって定義されています。 DNSSECは、データの認証を提供するために使用されます。相互運用性を確保するために、「実装が必須」のDNSKEYアルゴリズムのセットが定義されています。このドキュメントは廃止されました[RFC6944]。

1.1. Updating Algorithm Implementation Requirements and Usage Guidance

1.1. アルゴリズムの実装要件と使用ガイダンスの更新

The field of cryptography evolves continuously. New, stronger algorithms appear, and existing algorithms are found to be less secure than originally thought. Attacks previously thought to be computationally infeasible become more accessible as the available computational resources increase. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time to reflect the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise.

暗号化の分野は絶えず進化しています。新しい強力なアルゴリズムが登場し、既存のアルゴリズムは当初考えられていたよりも安全性が低いことが判明しています。以前は計算上実行不可能と考えられていた攻撃は、利用可能な計算リソースが増えるにつれて、よりアクセスしやすくなります。したがって、アルゴリズムの実装要件と使用方法のガイダンスは、新しい現実を反映するために時々更新する必要があります。アルゴリズムの妥協のリスクを最小限に抑えるために、アルゴリズムの選択は保守的である必要があります。

1.2. Updating Algorithm Requirement Levels

1.2. アルゴリズム要件レベルの更新

The mandatory-to-implement algorithm of tomorrow should already be available in most implementations of DNSSEC by the time it is made mandatory. This document attempts to identify and introduce those algorithms for future mandatory-to-implement status. There is no guarantee that algorithms in use today will become mandatory in the future. Published algorithms are continuously subjected to cryptographic attack and may become too weak or even be completely broken before this document is updated.

明日の実装に必須のアルゴリズムは、DNSSECのほとんどの実装で、必須にされるまでにすでに利用できるはずです。このドキュメントでは、これらのアルゴリズムを特定して導入し、将来の必須から実装までのステータスを示します。現在使用されているアルゴリズムが将来必須となる保証はありません。公開されているアルゴリズムは継続的に暗号攻撃を受けており、このドキュメントが更新される前に弱くなりすぎたり、完全に破壊されたりする可能性さえあります。

This document only provides recommendations with respect to mandatory-to-implement algorithms or algorithms so weak that they cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in this document MAY be implemented. For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded from a MUST or a RECOMMENDED to a MAY.

このドキュメントは、必須から実装までのアルゴリズム、または推奨できないほど弱いアルゴリズムに関する推奨のみを提供します。このドキュメントで言及されていない[DNSKEY-IANA]および[DS-IANA]レジストリにリストされているアルゴリズムは、実装される場合があります。明確化と一貫性のために、このドキュメントでは、MUSTまたはRECOMMENDEDからMAYに格下げされた場合にのみ、アルゴリズムをMAYとして指定します。

Although this document's primary purpose is to update algorithm recommendations to keep DNSSEC authentication secure over time, it also aims to do so in such a way that DNSSEC implementations remain interoperable. DNSSEC interoperability is addressed by an incremental introduction or deprecation of algorithms.

このドキュメントの主な目的は、DNSSEC認証を長期間にわたって安全に保つためにアルゴリズムの推奨事項を更新することですが、DNSSEC実装が相互運用性を維持できるようにすることも目的としています。 DNSSECの相互運用性は、アルゴリズムの段階的な導入または廃止により対処されます。

[RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and SHOULD NOT equivalent to NOT RECOMMENDED. The authors of this document have chosen to use the terms RECOMMENDED and NOT RECOMMENDED, as this more clearly expresses the intent to implementers.

[RFC2119]は、SHOULDはRECOMMENDEDと同等であり、SHOULD NOTはNOT RECOMMENDEDと同等であると見なします。このドキュメントの作成者は、RECOMMENDEDとNOT RECOMMENDEDという用語を使用することを選択しました。これにより、実装者の意図がより明確に表されます。

It is expected that deprecation of an algorithm will be performed gradually in a series of updates to this document. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a RECOMMENDED instead of a MUST.

このドキュメントの一連の更新では、アルゴリズムの廃止が段階的に行われることが期待されています。これにより、さまざまな実装が、相互運用性を維持しながら、実装されたアルゴリズムを更新する時間が提供されます。強力なセキュリティ上の理由がない限り、アルゴリズムは、MUST NOTではなく、MUST NOTからNOT RECOMMENDEDまたはMAYに格下げされることが期待されています。同様に、「実装が必須」として言及されていないアルゴリズムは、MUSTではなくRECOMMENDEDで導入されることが期待されています。

Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This will allow for deprecated algorithms to become less and less common over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT so that recursive resolvers can remove support for validating it.

不明なDNSKEYアルゴリズムを使用すると、ゾーンが安全ではないものとして扱われるため、権限のあるネームサーバーやDNSSEC署名者がアルゴリズムをNOT RECOMMENDED以下にダウングレードしないで、新しいDNSKEYを作成することをお勧めします。これにより、廃止されたアルゴリズムが次第に一般的でなくなります。アルゴリズムが十分に低いレベルのデプロイメントに達したら、再帰リゾルバーがそれを検証するためのサポートを削除できるように、アルゴリズムをNOT NOTとしてマークできます。

Recursive nameservers are encouraged to retain support for all algorithms not marked as MUST NOT.

再帰ネームサーバーは、MUST NOTとマークされていないすべてのアルゴリズムのサポートを保持することが推奨されます。

1.3. Document Audience

1.3. ドキュメントの対象者

The recommendations of this document mostly target DNSSEC implementers, as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth transition to more secure algorithms. This perspective may differ from that of a user who wishes to deploy and configure DNSSEC with only the safest algorithm. On the other hand, the comments and recommendations in this document are also expected to be useful for such users.

実装は、さまざまなベンダー間および異なるバージョン間での高いセキュリティの期待と高い相互運用性の両方を満たす必要があるため、このドキュメントの推奨事項は主にDNSSEC実装者を対象としています。相互運用性には、より安全なアルゴリズムへのスムーズな移行が必要です。この観点は、最も安全なアルゴリズムのみを使用してDNSSECを展開および構成することを望むユーザーの観点とは異なる場合があります。一方、このドキュメントのコメントと推奨事項は、このようなユーザーにも役立つと期待されます。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Algorithm Selection

3. アルゴリズムの選択

3.1. DNSKEY Algorithms

3.1. DNSKEYアルゴリズム

The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA].

次の表は、DNSKEYアルゴリズム[DNSKEY-IANA]の実装に関する推奨事項を示しています。

   +--------+--------------------+-----------------+-------------------+
   | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
   +--------+--------------------+-----------------+-------------------+
   | 1      | RSAMD5             | MUST NOT        | MUST NOT          |
   | 3      | DSA                | MUST NOT        | MUST NOT          |
   | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |
   | 6      | DSA-NSEC3-SHA1     | MUST NOT        | MUST NOT          |
   | 7      | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST              |
   | 8      | RSASHA256          | MUST            | MUST              |
   | 10     | RSASHA512          | NOT RECOMMENDED | MUST              |
   | 12     | ECC-GOST           | MUST NOT        | MAY               |
   | 13     | ECDSAP256SHA256    | MUST            | MUST              |
   | 14     | ECDSAP384SHA384    | MAY             | RECOMMENDED       |
   | 15     | ED25519            | RECOMMENDED     | RECOMMENDED       |
   | 16     | ED448              | MAY             | RECOMMENDED       |
   +--------+--------------------+-----------------+-------------------+

RSAMD5 is not widely deployed, and there is an industry-wide trend to deprecate MD5 usage.

RSAMD5は広く展開されておらず、MD5の使用を廃止する業界全体の傾向があります。

RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although the zones deploying it are recommended to switch to ECDSAP256SHA256 as there is an industry-wide trend to move to elliptic curve cryptography. RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3.

RSASHA1およびRSASHA1-NSEC3-SHA1は広く展開されていますが、楕円曲線暗号に移行する業界全体の傾向があるため、展開するゾーンはECDSAP256SHA256に切り替えることをお勧めします。 RSASHA1はNSEC3をサポートしていません。 RSASHA1-NSEC3-SHA1は、NSEC3の有無にかかわらず使用できます。

DSA and DSA-NSEC3-SHA1 are not widely deployed and are vulnerable to private key compromise when generating signatures using a weak or compromised random number generator.

DSAおよびDSA-NSEC3-SHA1は広く展開されておらず、弱いまたは危険にさらされた乱数ジェネレータを使用して署名を生成するときの秘密鍵の侵害に対して脆弱です。

RSASHA256 is widely used and considered strong. It has been the default algorithm for a number of years and is now slowly being replaced with ECDSAP256SHA256 due to its shorter key and signature size, resulting in smaller DNS packets.

RSASHA256は広く使用されており、強力と見なされています。これは何年もの間デフォルトのアルゴリズムでしたが、鍵と署名のサイズが短いためにECDSAP256SHA256に徐々に置き換えられ、DNSパケットが小さくなっています。

RSASHA512 is NOT RECOMMENDED for DNSSEC signing because it has not seen wide deployment, but there are some deployments; hence, DNSSEC validation MUST implement RSASHA512 to ensure interoperability. There is no significant difference in cryptographic strength between RSASHA512 and RSASHA256; therefore, use of RSASHA512 is discouraged as it will only make deprecation of older algorithms harder. People who wish to use a cryptographically stronger algorithm should switch to elliptic curve cryptography algorithms.

RSASHA512は広範囲に展開されていないため、DNSSEC署名には推奨されませんが、いくつかの展開があります。したがって、DNSSEC検証では、相互運用性を確保するためにRSASHA512を実装する必要があります。 RSASHA512とRSASHA256の間で暗号強度に大きな違いはありません。したがって、RSASHA512は古いアルゴリズムの廃止を難しくするだけなので、使用しないことをお勧めします。暗号的に強力なアルゴリズムを使用したい場合は、楕円曲線暗号アルゴリズムに切り替えてください。

ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in DNSSEC.

ECC-GOST（GOST R 34.10-2001）は、[RFC7091]でGOST R 34.10-2012に置き換えられました。 GOST R 34.10-2012は、DNSSECで使用するために標準化されていません。

ECDSAP256SHA256 provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256 has been widely deployed; therefore, it is now at MUST level for both validation and signing. It is RECOMMENDED to use the deterministic digital signature generation procedure of the Elliptic Curve Digital Signature Algorithm (ECDSA), specified in [RFC6979], when implementing ECDSAP256SHA256 (and ECDSAP384SHA384).

ECDSAP256SHA256は、RSASHA256またはRSASHA512のどちらよりも短い署名長でより高い暗号強度を提供します。 ECDSAP256SHA256は広く展開されています。したがって、検証と署名の両方で、MUSTレベルになります。 ECDSAP256SHA256（およびECDSAP384SHA384）を実装する場合は、[RFC6979]で指定されている楕円曲線デジタル署名アルゴリズム（ECDSA）の確定的デジタル署名生成手順を使用することをお勧めします。

ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256 but offers a modest security advantage over ECDSAP256SHA256 (192 bits of strength versus 128 bits). For most DNSSEC applications, ECDSAP256SHA256 should be satisfactory and robust for the foreseeable future and is therefore recommended for signing. While it is unlikely for a DNSSEC use case requiring 192-bit security strength to arise, ECDSA384SHA384 is provided for such applications, and it MAY be used for signing in these cases.

ECDSAP384SHA384はECDSAP256SHA256と同じプロパティを共有しますが、ECDSAP256SHA256よりも控えめなセキュリティ上の利点を提供します（128ビットの強度に対して128ビット）。ほとんどのDNSSECアプリケーションでは、ECDSAP256SHA256は予測可能な将来に備えて十分で堅牢であるため、署名に推奨されます。 192ビットのセキュリティ強度を必要とするDNSSECの使用例が発生する可能性は低いですが、ECDSA384SHA384はそのようなアプリケーション用に提供されており、これらの場合の署名に使用できます。

ED25519 and ED448 use the Edwards-curve Digital Security Algorithm (EdDSA). There are three main advantages of EdDSA: it does not require the use of a unique random number for each signature, there are no padding or truncation issues as with ECDSA, and it is more resilient to side-channel attacks. Furthermore, EdDSA cryptography is less prone to implementation errors ([RFC8032], [RFC8080]). It is expected that ED25519 will become the future RECOMMENDED default algorithm once there's enough support for this algorithm in the deployed DNSSEC validators.

ED25519およびED448は、エドワーズ曲線デジタルセキュリティアルゴリズム（EdDSA）を使用します。 EdDSAには主に3つの利点があります。シグネチャごとに一意の乱数を使用する必要がなく、ECDSAのようにパディングや切り捨ての問題がなく、サイドチャネル攻撃に対してより耐性があります。さらに、EdDSA暗号化は実装エラーが発生しにくい（[RFC8032]、[RFC8080]）。導入されたDNSSECバリデーターでこのアルゴリズムが十分にサポートされるようになると、ED25519が将来推奨されるデフォルトのアルゴリズムになると予想されます。

3.2. DNSKEY Algorithm Recommendation

3.2. DNSKEYアルゴリズムの推奨事項

Due to the industry-wide trend towards elliptic curve cryptography, ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade to ECDSAP256SHA256.

楕円曲線暗号化への業界全体の傾向により、ECDSAP256SHA256は新しいDNSSEC展開で使用するための推奨DNSKEYアルゴリズムであり、RSAベースのアルゴリズムのユーザーはECDSAP256SHA256にアップグレードする必要があります（SHOULD）。

3.3. DS and CDS Algorithms

3.3. DSおよびCDSアルゴリズム

The following table lists the recommendations for Delegation Signer Digest Algorithms [DS-IANA]. These recommendations also apply to the Child Delegation Signer (CDS) RRTYPE as specified in [RFC7344].

次の表に、委任署名者ダイジェストアルゴリズム[DS-IANA]の推奨事項を示します。これらの推奨事項は、[RFC7344]で指定されている子委任署名者（CDS）RRTYPEにも適用されます。

   +--------+-----------------+-------------------+-------------------+
   | Number | Mnemonics       | DNSSEC Delegation | DNSSEC Validation |
   +--------+-----------------+-------------------+-------------------+
   | 0      | NULL (CDS only) | MUST NOT [*]      | MUST NOT [*]      |
   | 1      | SHA-1           | MUST NOT          | MUST              |
   | 2      | SHA-256         | MUST              | MUST              |
   | 3      | GOST R 34.11-94 | MUST NOT          | MAY               |
   | 4      | SHA-384         | MAY               | RECOMMENDED       |
   +--------+-----------------+-------------------+-------------------+

[*] - This is a special type of CDS record signaling removal of DS at the parent in [RFC8078].

[*]-これは、[RFC8078]での親でのDSの削除を通知する特別なタイプのCDSレコードです。

NULL is a special case; see [RFC8078].

NULLは特殊なケースです。 [RFC8078]を参照してください。

SHA-1 is still widely used for Delegation Signer (DS) records, so validators MUST implement validation, but it MUST NOT be used to generate new DS and CDS records (see "Operational Considerations" for caveats when upgrading from the SHA-1 to SHA-256 DS algorithm.)

SHA-1は依然として委任署名者（DS）レコードに広く使用されているため、バリデーターは検証を実装する必要がありますが、新しいDSおよびCDSレコードを生成するために使用してはなりません（SHA-1からSHA-256 DSアルゴリズム。）

SHA-256 is widely used and considered strong.

SHA-256は広く使用されており、強力と見なされています。

GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in [RFC6986]. GOST R 34.11-2012 has not been standardized for use in DNSSEC.

GOST R 34.11-94は、[RFC6986]でGOST R 34.11-2012に置き換えられました。 GOST R 34.11-2012は、DNSSECで使用するために標準化されていません。

SHA-384 shares the same properties as SHA-256 but offers a modest security advantage over SHA-256 (384 bits of strength versus 256 bits). For most applications of DNSSEC, SHA-256 should be satisfactory and robust for the foreseeable future and is therefore recommended for DS and CDS records. While it is unlikely for a DNSSEC use case requiring 384-bit security strength to arise, SHA-384 is provided for such applications, and it MAY be used for generating DS and CDS records in these cases.

SHA-384はSHA-256と同じプロパティを共有しますが、SHA-256に比べてセキュリティ上の適度な利点を提供します（256ビットに対して384ビットの強度）。 DNSSECのほとんどのアプリケーションでは、SHA-256は予見可能な将来のために十分で堅牢である必要があるため、DSおよびCDSレコードに推奨されます。 384ビットのセキュリティ強度を必要とするDNSSECの使用例が発生する可能性は低いですが、SHA-384はそのようなアプリケーションに提供されており、これらの場合のDSおよびCDSレコードの生成に使用できます。

3.4. DS and CDS Algorithm Recommendation

3.4. DSおよびCDSアルゴリズムの推奨事項

An operational recommendation for new and existing deployments: SHA-256 is the RECOMMENDED DS and CDS algorithm.

新規および既存のデプロイメントの運用に関する推奨事項：SHA-256は、推奨されるDSおよびCDSアルゴリズムです。

4. Security Considerations

4. セキュリティに関する考慮事項

The security of cryptographic systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.

暗号化システムのセキュリティは、選択した暗号化アルゴリズムの強度と、それらのアルゴリズムで使用される鍵の強度の両方に依存します。セキュリティは、システム全体でのセキュリティを回避する非暗号化の方法がないことを保証するために、システムで使用されるプロトコルの設計にも依存します。

This document concerns itself with the selection of cryptographic algorithms for use in DNSSEC, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in this document as MUST or RECOMMENDED to implement are not known to be broken (in the cryptographic sense) at the current time, and cryptographic research so far leads us to believe that they are likely to remain secure into the foreseeable future. However, this isn't necessarily forever, and it is expected that new revisions of this document will be issued from time to time to reflect the current best practices in this area.

このドキュメントは、DNSSECで使用するための暗号化アルゴリズムの選択、特に「必須の実装」アルゴリズムの選択に関係しています。このドキュメントで実装が必須または推奨とされているアルゴリズムは、現時点では（暗号化の意味で）破損していることがわかっていないため、これまでのところ、暗号化の研究により、予測可能な将来においても安全性が維持される可能性が高いと考えられています。ただし、これは必ずしも永遠に続くわけではなく、このドキュメントの新しい改訂版が時々発行され、この領域の現在のベストプラクティスが反映されることが期待されています。

Retiring an algorithm too soon would result in a zone (signed with a retired algorithm) being downgraded to the equivalent of an unsigned zone. Therefore, algorithm deprecation must be done very slowly and only after careful consideration and measurement of its use.

アルゴリズムの廃止が早すぎると、ゾーン（廃止されたアルゴリズムで署名されたゾーン）が、署名されていないゾーンと同等にダウングレードされます。したがって、アルゴリズムの非推奨は、その使用を注意深く検討して測定した後にのみ、非常にゆっくりと実行する必要があります。

5. Operational Considerations

5. 運用上の考慮事項

DNSKEY algorithm rollover in a live zone is a complex process. See [RFC6781] and [RFC7583] for guidelines on how to perform algorithm rollovers.

ライブゾーンでのDNSKEYアルゴリズムのロールオーバーは複雑なプロセスです。アルゴリズムのロールオーバーを実行する方法のガイドラインについては、[RFC6781]および[RFC7583]を参照してください。

DS algorithm rollover in a live zone is also a complex process. Upgrading an algorithm at the same time as rolling a new Key Signing Key (KSK) will lead to DNSSEC validation failures. Administrators MUST complete the process of the DS algorithm upgrade before starting a rollover process for a new KSK.

ライブゾーンでのDSアルゴリズムのロールオーバーも複雑なプロセスです。アルゴリズムをアップグレードすると同時に新しいキー署名キー（KSK）をローリングすると、DNSSEC検証エラーが発生します。管理者は、新しいKSKのロールオーバープロセスを開始する前に、DSアルゴリズムのアップグレードプロセスを完了する必要があります。

6. IANA Considerations

6. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[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, <https://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月、< https://www.rfc-editor.org/info/rfc4034>。

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/info/rfc5155>.

[RFC5155] Laurie、B.、Sisson、G.、Arends、R。、およびD. Blacka、「DNS Security（DNSSEC）Hashed Authenticated Denial of Existence」、RFC 5155、DOI 10.17487 / RFC5155、2008年3月、<https： //www.rfc-editor.org/info/rfc5155>。

[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, <https://www.rfc-editor.org/info/rfc5702>.

[RFC5702] Jansen、J。、「DNSKEYでのRSAを使用したSHA-2アルゴリズムとDNSSECのRRSIGリソースレコードの使用」、RFC 5702、DOI 10.17487 / RFC5702、2009年10月、<https://www.rfc-editor.org / info / rfc5702>。

[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <https://www.rfc-editor.org/info/rfc6605>.

[RFC6605] Hoffman、P。およびW. Wijngaards、「DNSSECの楕円曲線デジタル署名アルゴリズム（DSA）」、RFC 6605、DOI 10.17487 / RFC6605、2012年4月、<https://www.rfc-editor.org/info / rfc6605>。

[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.

[RFC6979]ポルノ、T。、「デジタル署名アルゴリズム（DSA）と楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用法」、RFC 6979、DOI 10.17487 / RFC6979、2013年8月、<https：//www.rfc- editor.org/info/rfc6979>。

[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, <https://www.rfc-editor.org/info/rfc6986>.

[RFC6986] Dolmatov、V.、Ed。およびA. Degtyarev、「GOST R 34.11-2012：Hash Function」、RFC 6986、DOI 10.17487 / RFC6986、2013年8月、<https://www.rfc-editor.org/info/rfc6986>。

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-editor.org/info/rfc7344>.

[RFC7344] Kumari、W.、Gudmundsson、O。、およびG. Barwood、「Automating DNSSEC Delegation Trust Maintenance」、RFC 7344、DOI 10.17487 / RFC7344、2014年9月、<https://www.rfc-editor.org/ info / rfc7344>。

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.

[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。

[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, <https://www.rfc-editor.org/info/rfc8078>.

[RFC8078] Gudmundsson、O。およびP. Wouters、「CDS / CDNSKEYを介した親からのDSレコードの管理」、RFC 8078、DOI 10.17487 / RFC8078、2017年3月、<https://www.rfc-editor.org/info / rfc8078>。

[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017, <https://www.rfc-editor.org/info/rfc8080>.

[RFC8080]スリー、O.、R。エドモンズ、「DNSSECのエドワーズカーブデジタルセキュリティアルゴリズム（EdDSA）」、RFC 8080、DOI 10.17487 / RFC8080、2017年2月、<https://www.rfc-editor.org/ info / rfc8080>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

7.2. Informative References

7.2. 参考引用

[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 2010, <https://www.rfc-editor.org/info/rfc5933>.

[RFC5933] Dolmatov、V.、Ed。、Chuprina、A。、およびI. Ustinov、「DNSKEYおよびRRSIGリソースレコードでのGOST署名アルゴリズムのDNSSECへの使用」、RFC 5933、DOI 10.17487 / RFC5933、2010年7月、<https ：//www.rfc-editor.org/info/rfc5933>。

[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-editor.org/info/rfc6781>.

[RFC6781] Kolkman、O.、Mekking、W。、およびR. Gieben、「DNSSEC Operational Practices、Version 2」、RFC 6781、DOI 10.17487 / RFC6781、2012年12月、<https://www.rfc-editor.org / info / rfc6781>。

[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", RFC 6944, DOI 10.17487/RFC6944, April 2013, <https://www.rfc-editor.org/info/rfc6944>.

[RFC6944] Rose、S。、「Applicability Statement：DNS Security（DNSSEC）DNSKEY Algorithm Implementation Status」、RFC 6944、DOI 10.17487 / RFC6944、2013年4月、<https://www.rfc-editor.org/info/rfc6944 >。

[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, <https://www.rfc-editor.org/info/rfc7091>.

[RFC7091] Dolmatov、V.、Ed。およびA. Degtyarev、「GOST R 34.10-2012：Digital Signature Algorithm」、RFC 7091、DOI 10.17487 / RFC7091、2013年12月、<https://www.rfc-editor.org/info/rfc7091>。

[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 10.17487/RFC7583, October 2015, <https://www.rfc-editor.org/info/rfc7583>.

[RFC7583] Morris、S.、Ihren、J.、Dickinson、J。、およびW. Mekking、「DNSSECキーロールオーバーのタイミングに関する考慮事項」、RFC 7583、DOI 10.17487 / RFC7583、2015年10月、<https：//www.rfc -editor.org/info/rfc7583>。

[DNSKEY-IANA] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", <http://www.iana.org/assignments/dns-sec-alg-numbers>.

[DNSKEY-IANA] IANA、「ドメインネームシステムセキュリティ（DNSSEC）アルゴリズム番号」、<http://www.iana.org/assignments/dns-sec-alg-numbers>。

[DS-IANA] IANA, "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms", <http://www.iana.org/assignments/ds-rr-types>.

[DS-IANA] IANA、「委任署名者（DS）リソースレコード（RR）タイプダイジェストアルゴリズム」、<http://www.iana.org/assignments/ds-rr-types>。

Acknowledgements

謝辞

This document borrows text from RFC 4307 by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT) and RFC 8247 by Yoav Nir, Tero Kivinen, Paul Wouters, and Daniel Migault. Much of the original text has been copied verbatim.

このドキュメントは、マサチューセッツ工科大学（MIT）のJeffrey I. SchillerによるRFC 4307と、Yoav Nir、Tero Kivinen、Paul Wouters、およびDaniel MigaultによるRFC 8247からテキストを借用したものです。元のテキストの多くはそのままコピーされています。

We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman, Evan Hunt, and Peter Yee for their feedback.

Michael Sinatra、Roland van Rijswijk-Deij、Olafur Gudmundsson、Paul Hoffman、Evan Hunt、およびPeter Yeeのフィードバックに感謝します。

Kudos to Roy Arends for bringing the DS rollover issue to light.

DSロールオーバーの問題が明らかになったことに対するRoy Arendsへの称賛。

Authors' Addresses

著者のアドレス

Paul Wouters Red Hat Canada

   Email: pwouters@redhat.com

Ondrej Sury Internet Systems Consortium Czech Republic

Ondrej Sury Internet Systems Consortiumチェコ共和国

   Email: ondrej@isc.org