ネットワークワーキンググループ J. Jansen Request for Comments: 5702 NLnet Labs 分類: 標準化過程(Standards Track) 2009年11月 DNSSECのDNSKEY、RRSIGリソースレコードへの RSA/SHA-2アルゴリズムの導入 要旨 本文書はDNSセキュリティ拡張(DNSSEC: RFC 4033, RFC4034, RFC4035)において、 RSA/SHA-256およびRSA/SHA-512を使用するDNSKEYおよびRRSIGリソースレコードの 生成法を記述する。 本文書の位置づけ 本文書はインターネットコミュニティのためにインターネット標準化過程に あるプロトコルを規定し、改善に向けた議論と提案を求めるものである。 このプロトコルの標準化の状況については"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。本文書の配布は制限されない。 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 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 BSD License. Jansen Standards Track [Page 1] RFC 5702 DNSSEC RSA/SHA-2 October 2009 目次 1. はじめに ........................................................2 2. DNSKEYリソースレコード ..........................................3 2.1. RSA/SHA-256を使用するDNSKEYリソースレコード ................3 2.2. RSA/SHA-512を使用するDNSKEYリソースレコード ................3 3. RRSIGリソースレコード ...........................................3 3.1. RSA/SHA-256を使用するRRSIGリソースレコード .................4 3.2. RSA/SHA-512を使用するRRSIGリソースレコード .................4 4. 展開に関する考慮点 ..............................................5 4.1. 鍵長 .......................................................5 4.2. 署名サイズ .................................................5 5. 実装に関する考慮点 ..............................................5 5.1. SHA-2署名のサポート ........................................5 5.2. NSEC3不在証明のサポート ....................................5 6. 例 ..............................................................6 6.1. RSA/SHA-256を使用する鍵および署名の例 ......................6 6.2. RSA/SHA-512を使用する鍵および署名の例 ......................7 7. IANAに関する考慮点 ..............................................8 8. セキュリティに関する考慮点 ......................................8 8.1. RRSIGリソースレコードにおけるSHA-1とSHA-2の比較 ............8 8.2. 署名ダウングレード攻撃 .....................................8 9. Acknowledgments .................................................9 10. References .....................................................9 10.1. Normative References ......................................9 10.2. Informative References ....................................9 1. はじめに DNS(Domain Name System)はグローバルで階層的に分散した、インターネットの 名前に関するデータベースである。DNSは拡張され、暗号鍵とデジタル署名を 使用して、データの出自・完全性を検証できるようになった。[RFC4033]、 [RFC4034]、[RFC4035]でこれらのDNSセキュリティ拡張を記述している。 この拡張をDNSSECと呼ぶ。 RFC 4034は、DNSKEYおよびRRSIGリソースレコードを格納する方法を記述し、 使用する暗号アルゴリズムのリストを規定している。本文書はこのリストを 拡張し、RSA/SHA-256およびRSA/SHA-512を加えるとともに、これらのハッシュ アルゴリズムを使用したDNSKEYデータの格納方法、RRSIGリソースレコードの 生成法を規定する。 読者は、DNSSEC、RSA、SHA-2 [FIPS.180-3.2008]アルゴリズムファミリーに 精通していることを前提とする。 Jansen Standards Track [Page 2] RFC 5702 DNSSEC RSA/SHA-2 October 2009 読者の読みやすさを向上させるために、本文書ではSHA-256およびSHA-512の 両方を参照する用語として、SHA-2という名称を使用する。ただし、記述が SHA-256またはSHA-512固有のものである場合、その固有の名称を使用する。 同様に、RSA/SHA-256およびRSA/SHA-512の両方を参照する用語として、 RSA/SHA-2という名称を使用する。 "SHA-2"という用語は正式に定義されたものであるが、通常SHA-224、SHA-256、 SHA-384、SHA-512といったアルゴリズムファミリーを参照するために使用される。 SHA-224およびSHA-384はDNSSECでは使用しないので、本文書においてSHA-2という 用語はSHA-256およびSHA-512だけを参照するものとする。 本文書におけるキーワード"しなければならない(MUST)"、"してはならない (MUST NOT)"、"要求される(REQUIRED)"、"するものとする(SHALL)"、"しな いものとする(SHALL NOT)"、"すべきである(SHOULD)"、"すべきでない (SHOULD NOT)"、"推奨される(RECOMMENDED)"、"してもよい/することがで きる(MAY)"、"任意である(OPTIONAL)"は、[RFC2119]に記述されているとお りに解釈するものとする。 2. DNSKEYリソースレコード DNSKEY RRのフォーマットは[RFC4034]に記載がある。RSA/SHA-1をDNSSEC署名で 使用する方法については[RFC3110]に記載がある。 2.1. RSA/SHA-256を使用するDNSKEYリソースレコード RSA/SHA-256を使用するRSA公開鍵は、アルゴリズム番号8を指定した DNSKEYリソースレコードに格納される。 相互運用性を維持するために、[RFC3110]の規定と同様に、RSA/SHA-256を使用する 鍵の鍵長は512ビット未満であっても4096ビットを越えてもいけない (MUST NOT)。 2.2. RSA/SHA-512を使用するDNSKEYリソースレコード RSA/SHA-512を使用するRSA公開鍵は、アルゴリズム番号10を指定した DNSKEYリソースレコードに格納される。 RSA/SHA-512を使用する鍵の鍵長は1024ビット未満であっても4096ビットを 越えてもいけない(MUST NOT)。 3. RRSIGリソースレコード RRSIG RRの署名フィールドはRSASSA-PKCS1-v1_5の署名方式に従い、以下のように 計算される。RDATAフィールドの署名データの前に格納される様々な値 (訳注: 署名対象タイプ、アルゴリズムから署名者名まで)は[RFC4034]で 規定される。 Jansen Standards Track [Page 3] RFC 5702 DNSSEC RSA/SHA-2 October 2009 ハッシュ = SHA-XXX(データ) ここで、XXXはFIPS PUB 180-3の規定に従い、使用するアルゴリズムに応じて 256か512のどちらかとなる。"データ"とは、[RFC4034]の規定に従い、 署名されるRRsetのワイヤーフォーマットデータである。 署名 = ( 00 | 01 | FF* | 00 | プレフィックス | ハッシュ ) ** e (mod n) ここで"|"は連結(concatenation)であり、"00"、"01"、"FF"、"00"は、16進数で 表記された固定オクテット値である。"e"は署名に使用するRSA鍵の秘密鍵の指数 (private exponent)であり、"n"は署名鍵のモジュラス(public modulus)である。 FF値を採るオクテットは丸括弧内の各項の長さが署名者の公開鍵のビット列表現 ("n")と同じ長さになるまで繰り返されなければならない(MUST)。 "プレフィックス"は標準的な暗号ライブラリの使用を容易にすることを意図した ものである。プレフィックスの仕様はPKCS #1 v2.1のRSASSA-PKCS1-v1_5仕様 ([RFC3447]のセクション8.2)およびPKCS #1 v2.1のEMSA-PKCS1-v1_5 エンコーディング([RFC3447]のセクション9.2)を直接取り込んだものである。 異なるアルゴリズム用のプレフィックスについては以下で規定する。 3.1. RSA/SHA-256を使用するRRSIGリソースレコード RSA/SHA-256で生成された署名は、アルゴリズム番号8を指定したRRSIGリソース レコード(RR)に格納される。 プレフィックスはASN.1 DER SHA-256のアルゴリズム指定プレフィックスであり、 PKCS #1 v2.1 [RFC3447]で規定される。 (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 3.2. RSA/SHA-512を使用するRRSIGリソースレコード RSA/SHA-512で生成された署名は、アルゴリズム番号10を指定したRRSIGリソース レコード(RR)に格納される。 プレフィックスはASN.1 DER SHA-512のアルゴリズム指定プレフィックスであり、 PKCS #1 v2.1 [RFC3447]で規定される。 (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 Jansen Standards Track [Page 4] RFC 5702 DNSSEC RSA/SHA-2 October 2009 4. 展開に関する考慮点 4.1. 鍵長 セクション2の制約はあるものの、本文書は使用すべき鍵長を指定しない。 鍵長は運用上の問題であり、環境と鍵の用途に大きく依存する。 NIST SP 800-57 [NIST800-57] がより詳細な情報への良い足がかりになるだろう。 4.2. 署名サイズ この署名アルゴリズムファミリーでは、署名サイズは鍵長と相関するが、 署名処理で使用するハッシュアルゴリズムには依存しない。したがって、使用する 鍵長が同じであるならば、RSA/SHA-256またはRSA/SHA-512で生成する RRSIG RRのサイズはRSA/SHA-1で生成するRRSIG RRのサイズと同じになる。 5. 実装に関する考慮点 5.1. SHA-2署名のサポート DNSSEC対応実装は、RSA/SHA-2アルゴリズムにより生成されるRRSIG RR およびDNSKEY RRを本文書の定義どおりにサポートすべきである(SHOULD)。 5.2. NSEC3不在証明のサポート [RFC5155]は既存の署名アルゴリズムに対して新しいアルゴリズムID(訳注: アルゴリズムの別名)を定義している。新しいアルゴリズムIDで署名された ゾーンでは、不在を証明するためにNSECレコードに加えてNSEC3レコードも使用 できることを示すためである。この仕組みは、RFC 5155以前の実装が(その実装に とって)未知のリソースレコードに遭遇することを防ぐために選択された。 本文書では、そのようなアルゴリズムの別名は定義しない。 RSA/SHA-2を実装するDNSSECバリデータは、ハッシュアルゴリズム1を使用する NSECおよびNSEC3両方式の不在応答を[RFC5155]の定義どおりに検証できなければ ならない(MUST)。NSEC3を実装していない権威サーバは、RSA/SHA-2を使用する NSEC不在証明を含むゾーンを提供してもよい(MAY)。 Jansen Standards Track [Page 5] RFC 5702 DNSSEC RSA/SHA-2 October 2009 6. 例 6.1. RSA/SHA-256を使用する鍵および署名の例 以下に示す(Base64エンコード)値を持つ秘密鍵があるものとする。 Private-key-format: v1.2 Algorithm: 8 (RSASHA256) Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== PublicExponent: AQAB PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/ HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ== Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk= Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE= Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk= Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE= Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q= この鍵に対応するDNSKEYレコードは以下のようになる。 example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} この鍵を使用して、以下のようなAレコード1つで構成されるRRsetに署名する 場合を考える。 www.example.net. 3600 IN A 192.0.2.91 有効期間開始時刻が2000年1月1日00:00であり、有効期間終了時刻が 2030年1月1日00:00である場合、以下の署名が生成されるはずである。 www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa cFYK/lPtPiVYP4bwg==);{id = 9033} Jansen Standards Track [Page 6] RFC 5702 DNSSEC RSA/SHA-2 October 2009 6.2. RSA/SHA-512を使用する鍵および署名の例 以下に示す(Base64エンコード)値を持つ秘密鍵があるものとする。 Private-key-format: v1.2 Algorithm: 10 (RSASHA512) Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V jXZlNKdyit99waaE4s= PublicExponent: AQAB PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6 AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3 SEIAsrB043XzGrKIVE= Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ== Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw== Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q== Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w== Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ== この鍵に対応するDNSKEYレコードは以下のようになる。 example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL );{id = 3740 (zsk), size = 1024b} この鍵を使用して、以下のようなAレコード1つで構成されるRRsetに署名する 場合を考える。 www.example.net. 3600 IN A 192.0.2.91 有効期間開始時刻が2000年1月1日00:00であり、有効期間終了時刻が 2030年1月1日00:00である場合、以下の署名が生成されるはずである。 www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw =);{id = 3740} Jansen Standards Track [Page 7] RFC 5702 DNSSEC RSA/SHA-2 October 2009 7. IANAに関する考慮点 本文書はIANAレジストリの "DNS SECURITY ALGORITHM NUMBERS -- per [RFC4035]" (訳注: 現在は "DNS Security (DNSSEC) Algorithm Numbers" ) (http://www.iana.org/protocols)を更新する。以下のエントリがレジストリに 追加される。 ゾーン トランザクション 値 記述 ニーモニック 署名 セキュリティ 参照 -------------------------------------------------------------------------- 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 10 RSA/SHA-512 RSASHA512 Y * RFC 5702 ・このアルゴリズムをトランザクションセキュリティで使用する方式の 標準化については何も合意がなされていない。 8. セキュリティに関する考慮点 8.1. RRSIGリソースレコードにおけるSHA-1とSHA-2の比較 DNSSECユーザは、ソフトウェア実装が対応したならば直ちにSHA-2を展開する ことを推奨する。SHA-2はSHA-1よりも攻撃に対して耐性があると広く信じられて いる。一方でSHA-1の強さに対する信頼は、最近明らかになった攻撃により徐々に 弱まりつつある。SHA-1への攻撃がDNSSECに影響を与えるかどうかに関わらず、 (本文書執筆時点においては)DNSSECレコードにおける使用にはSHA-2がより良い 選択肢であると信じられている。 SHA-2は当面の間は充分な暗号強度があると考えられている。暗号技術や 暗号解析技術の今後の発展予測については本文書の対象外である。 RSASSA-PKCS1-v1_5署名方式が選択された理由は、RSA/SHA-1署名で使用されて いるものと対応させるためである。これにより、DNSSECソフトウェアで新しい ハッシュアルゴリズムを実装することが容易になるはずである。 8.2. 署名ダウングレード攻撃 各RRsetはゾーン頂点に存在するDNSKEY RRsetに含まれる各アルゴリズムで 署名されなければならない(MUST)ため([RFC4035]のセクション2.2参照)、 ゾーンにRSA/SHA-2とRSA/SHA-1の両方の署名が存在する場合、悪意ある者は RSA/SHA-2 RRSIGを排除してバリデータにRSA/SHA-1を使用するよう 仕向けることができない。したがって、バリデータがRSA/SHA-2をサポートする 場合、ダウングレード攻撃への耐性を提供するはずである。 Jansen Standards Track [Page 8] RFC 5702 DNSSEC RSA/SHA-2 October 2009 9. Acknowledgments This document is a minor extension to [RFC4034]. Also, we try to follow the documents [RFC3110] and [RFC4509] for consistency. The authors of and contributors to these documents are gratefully acknowledged for their hard work. The following people provided additional feedback and text: Jaap Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, Michael St. Johns, and Wouter Wijngaards. 10. References 10.1. Normative References [FIPS.180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [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. 10.2. Informative References [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendations for Key Management", NIST SP 800-57, March 2007. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. Jansen Standards Track [Page 9] RFC 5702 DNSSEC RSA/SHA-2 October 2009 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. Author's Address Jelte Jansen NLnet Labs Science Park 140 1098 XG Amsterdam NL EMail: jelte@NLnetLabs.nl URI: http://www.nlnetlabs.nl/ Jansen Standards Track [Page 10]