ネットワークワーキンググループ W. Hardaker Request for Comments: 4509 Sparta 分類: 標準化過程(Standards Track) 2006年5月 DNSSECのDS(Delegation Signer)リソースレコード(RR)におけるSHA-256の使用 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (2006). 要旨 本文書は、DNSのDS(Delegation Signer)リソースレコード(RR)でSHA-256 ダイジェストタイプを使用する方法を規定する。DSレコードは親ゾーンに 保存され、子ゾーンのDNSKEYを参照するものである。 目次 1. はじめに .......................................................2 2. DSレコードをサポートするSHA-256アルゴリズムの実装 ..............2 2.1. DSレコードのフィールド値 ..................................2 2.2. SHA-256を使用するDSレコードのワイヤーフォーマット .........3 2.3. SHA-256を使用するDSレコードの例 ...........................3 3. 実装の要件 .....................................................3 4. 展開に関する考慮点 .............................................4 5. IANAに関する考慮点 .............................................4 6. セキュリティに関する考慮点 .....................................4 6.1. ダイジェストタイプダウングレード攻撃の可能性 ..............4 6.2. DSレコードにおけるSHA-1とSHA-256の対比 ....................5 7. Acknowledgements ................................................5 8. References ......................................................6 8.1. Normative References .......................................6 8.2. Informative References .....................................6 Hardaker Standards Track [Page 1] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 1. はじめに DNSSEC[RFC4033][RFC4034][RFC4035]のDS RRは、子ゾーンのDNSKEY RRsetに 含まれる1つの鍵の暗号ダイジェストを配布するために、親ゾーンで公開される ものである。DS RRsetは、親ゾーンのゾーンデータに署名する最低1つの秘密鍵で 署名される。署名生成に使用されるアルゴリズムは、親ゾーンで使用される 各アルゴリズムの1つである。各署名は、DS RRsetと同じドメインが保持し、 DSリソースレコードを署名対象とするRRSIGリソースレコードとして公開される。 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、[RFC2119]に記述されているとお りに解釈するものとする。 2. DSレコードをサポートするSHA-256アルゴリズムの実装 本文書において、DSレコードにおけるSHA-256[SHA256][SHA256CODE]使用のために ダイジェストタイプコード2を割り当てる。ダイジェストアルゴリズムの出力を 切り詰めてはならず(MUST NOT)、32バイトのダイジェスト出力全てがDSレコードで 公開される。 2.1. DSレコードのフィールド値 SHA-256ダイジェストアルゴリズムをDSレコードで使用する場合、以下の DSレコードのフィールド値が使用される。 ダイジェストタイプ: 2 ダイジェスト: 以下の式を使用してSHA-256ビットダイジェスト値を計算する ("|"は連結(concatenation)を表す)。出力される値は切り詰められず、 32バイトの出力全てがDSレコードに保存される。関連する計算でも 32バイト全てが使用される。 ダイジェスト値 = SHA_256(DNSKEYの所有者名 | DNSKEY RDATA) ここで、DNSKEY RDATAは[RFC4034]で以下のように定義されている。 DNSKEY RDATA = フラグ | プロトコル | アルゴリズム | 公開鍵 鍵タグフィールドおよびアルゴリズムフィールドは本文書で変更せず、 [RFC4034]仕様で規定されるものをそのまま使用する。 Hardaker Standards Track [Page 2] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 2.2. SHA-256を使用するDSレコードのワイヤーフォーマット SHA-256を使用するDSレコードのネットワークを流れる(on-the-wire) フォーマットは以下のようになる。 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 鍵タグ | アルゴリズム | ダイジェスト | | | | タイプ = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / ダイジェスト (SHA-256の長さは32バイト) / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2.3. SHA-256を使用するDSレコードの例 以下にDNSKEYと、それを参照するDSレコードの例を示す。DNSKEYは[RFC4034]の セクション5.4に記載があるDNSKEY/DSレコードのサンプルと同じものである。 DNSKEYレコード: dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz fwJr1AYtsmx3TGkJaNXVbfi/ 2pHm822aJ5iI9BMzNXxeYCmZ DRD99WYwYqUSdjMmmAphXdvx egXd/M5+X7OrzKBaMbCVdFLU Uh6DhweJBjEVv5f2wwjM9Xzc nOf+EPbtG9DMBmADjFDc2w/r ljwvFw== ) ; key id = 60485 上記のDNSKEYレコードに対応する、SHA-256ダイジェストを使用した DSレコード: dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C CEB1E3E0614B93C4F9E99B83 83F6A1E4469DA50A ) 3. 実装の要件 実装はDS RRにおけるSHA-256アルゴリズムの使用をサポートしなければ ならない(MUST)。SHA-256ダイジェストを使用するDS RRがDS RRsetに存在する 場合、バリデータ実装はSHA-1を使用するDS RRを無視すべきである(SHOULD)。 Hardaker Standards Track [Page 3] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 4. 展開に関する考慮点 バリデータがSHA-256ダイジェストタイプをサポートしておらず、ゾーンの DS RRset内に当該バリデータのサポートするダイジェストタイプのDS RRが 存在しない場合、バリデータは親ゾーンから子ゾーンへの認証の連鎖をサポート できない。この場合、リゾルバは[RFC4035]セクション5.2記載の"ゾーンに DS RRsetが存在しないことを証明するNSEC RRsetを認証した場合"と同様に 扱うべきである。 ゾーン管理者は、管理するゾーンを参照するバリデータにSHA-256のサポートが 普及していく速さを制御できないので、ゾーン運用者はSHA-1とSHA-256両方を 使用するDSレコードの展開を考慮すべきである。これはDSレコードが生成される 全てのDNSKEYに対しても行われるべきである。両方のダイジェストタイプを使用 するかどうか、またその期間についてはポリシーの問題であり、本文書の 対象範囲外である。 5. IANAに関する考慮点 本文書は1つだけIANAの作業を要求する。 DSレコードでSHA-256をサポートするために使用するダイジェストタイプを IANAが割り当てている。 本文書執筆時点において、DSレコードで使用されるダイジェストタイプは 以下のとおりである。 値 ダイジェストタイプ 状態 ------------------------------------------- 0 予約済 - 1 SHA-1 必須 2 SHA-256 必須 3-255 未割当 - 6. セキュリティに関する考慮点 6.1. ダイジェストタイプダウングレード攻撃の可能性 以下の条件が全て満たされる場合、強いダイジェストタイプを弱いものに ダウングレードする攻撃が可能である。 ・ 子ゾーンのDNSKEYに対して親ゾーンが複数のDSレコードを持ち、それぞれが 異なるダイジェストタイプを使用している。 ・ バリデータは、強いダイジェストが無効である場合、弱いダイジェストを 受理する。 Hardaker Standards Track [Page 4] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 例えば、以下の条件が全て満たされた場合が相当する。 ・ 子ゾーンのDNSKEYに対して、親ゾーンでSHA-1を使用するDSレコードと SHA-256を使用するDSレコードの両方が公開されている。 ・ 片方のDSレコードが保持するSHA-1ダイジェストは、子ゾーンのDNSKEYから 計算されたダイジェストと一致する。 ・ もう片方のDSレコードが保持するSHA-256ダイジェストは、子ゾーンの DNSKEYから計算されたダイジェストと一致しない。 バリデータが上記の状況を"Secure(検証成功：信頼度高)"として受理する場合、 SHA-256ダイジェストが無視されるので、このような状況をダウングレード攻撃に 使用できてしまう。 6.2. DSレコードにおけるSHA-1とSHA-256の対比 DNSSECユーザは、ソフトウェア実装が対応したならば直ちにSHA-256を展開する ことを推奨する。SHA-256はSHA-1よりも攻撃に対して耐性があると広く信じられて いる。一方でSHA-1の強さに対する信頼は、最近明らかになった攻撃により徐々に 弱まりつつある。SHA-1への攻撃がDNSSECに影響を与えるかどうかに関わらず、 (本文書執筆時点においては)DSレコードにおける使用にはSHA-256がより良い 選択肢であると信じられている。 本文書公開時点において、SHA-256ダイジェストアルゴリズムは当面の間は 充分に強く、DNSSECのDS RRでの使用には充分だと考えられている。 しかし、将来において公開される攻撃により、DS RRで使用されるこの アルゴリズムの有用性が弱体化する可能性はある。SHA-256ダイジェスト アルゴリズムの暗号強度を広範囲に予測することは本文書の対象範囲外である。 同様に、SHA-1を使用するDSレコードをSHA-256を使用するDSレコードと併せて 公開すべきか、またどの程度の期間それを維持すべきかについても本文書の 対象範囲外である。 7. Acknowledgements This document is a minor extension to the existing DNSSEC documents and those authors are gratefully appreciated for the hard work that went into the base documents. The following people contributed to portions of this document in some fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam Weiler. Hardaker Standards Track [Page 5] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [SHA256] National Institute of Standards and Technology, "Secure Hash Algorithm. NIST FIPS 180-2", August 2002. 8.2. Informative References [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in Progress. Author's Address Wes Hardaker Sparta P.O. Box 382 Davis, CA 95617 USA EMail: hardaker@tislabs.com Hardaker Standards Track [Page 6] RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hardaker Standards Track [Page 7]