| CARVIEW |
Select Language
HTTP/1.1 200 OK
Date: Mon, 14 Jul 2025 23:29:03 GMT
Last-Modified: Tue, 13 Jun 2023 05:32:56 GMT
ETag: "40c4-5fdfc2ad8f200"
Accept-Ranges: bytes
Content-Length: 16580
Content-Type: text/plain; charset=utf-8
Strict-Transport-Security: max-age=2592000
ネットワークワーキンググループ 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
https://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]