One document matched: draft-ietf-dnsext-dnssec-rsasha256-03.xml
<?xml version="1.0"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="full3978" docName="draft-ietf-dnsext-dnssec-rsasha256-03">
<front>
<title abbrev="DNSSEC RSA/SHA-2">Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC</title>
<author initials="J.R.P." surname="Jansen"
fullname="Jelte Jansen">
<organization>NLnet Labs</organization>
<address>
<postal>
<street>Kruislaan 419</street>
<city>Amsterdam</city>
<code>1098VA</code>
<country>NL</country>
</postal>
<email>jelte@NLnetLabs.nl</email>
<uri>http://www.nlnetlabs.nl/</uri>
</address>
</author>
<date day="16" month="February" year="2008" />
<area>General</area>
<workgroup>DNS Extensions working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>DNSSEC</keyword>
<keyword>RSA</keyword>
<keyword>SHA-256</keyword>
<keyword>SHA-512</keyword>
<abstract>
<t>
This document describes how to produce RSA/SHA-256
and RSA/SHA-512 DNSKEY and RRSIG resource records for
use in the Domain Name System Security Extensions
(DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The Domain Name System (DNS) is the global
hierarchical distributed database for Internet
Addressing. The DNS has been extended to use
cryptographic keys and digital signatures for the
verification of the integrity of its data. RFC 4033
<xref target="RFC4033"/>, RFC 4034
<xref target="RFC4034"/>, and RFC 4035
<xref target="RFC4035"/> describe these DNS
Security Extensions, called DNSSEC.
</t>
<t>
RFC 4034 describes how to store DNSKEY and RRSIG
resource records, and specifies a list of
cryptographic algorithms to use. This document
extends that list with the algorithms RSA/SHA-256
and RSA/SHA-512, and specifies how to store DNSKEY
data and how to produce RRSIG resource records with
these hash algorithms.
</t>
<t>
Familiarity with DNSSEC, RSA
<xref target="SCHNEIER-1996"/> and the SHA-2
<xref target="FIPS.180-2.2002" /> family of
algorithms is assumed in this document.
</t>
<t>
To refer to both SHA-256 and SHA-512, this document
will use the name SHA-2. This is done to improve
readability. When a part of text is specific for
either SHA-256 or SHA-512, their specific names are
used. The same goes for RSA/SHA-256 and
RSA/SHA-512, which will be grouped using the name
RSA/SHA-2.
</t>
</section>
<section anchor="dnskey" title="DNSKEY Resource Records">
<t>
The format of the DNSKEY RR can be found in RFC 4034
<xref target="RFC4034"/> and RFC 3110
<xref target="RFC3110"/>.
</t>
<section anchor="dnskey-rsasha256" title="RSA/SHA-256 DNSKEY Resource Records">
<t>
RSA public keys for use with RSA/SHA-256 are stored
in DNSKEY resource records (RRs) with the algorithm
number {TBA1}.
</t>
<t>
For use with NSEC3, the algorithm number of
RSA/SHA-256 will be {TBA2}.
</t>
<t>
The key size for RSA/SHA-256 keys MUST NOT be less
than 512 bits, and MUST NOT be more than 4096 bits.
</t>
</section>
<section anchor="dnskey-rsasha512" title="RSA/SHA-512 DNSKEY Resource Records">
<t>
RSA public keys for use with RSA/SHA-512 are stored
in DNSKEY resource records (RRs) with the algorithm
number {TBA3}.
</t>
<t>
For use with NSEC3, the algorithm number of
RSA/SHA-512 will be {TBA4}.
</t>
<t>
The key size for RSA/SHA-512 keys MUST NOT be less
than 1024 bits, and MUST NOT be more than 4096 bits.
</t>
</section>
</section>
<section anchor="rrsig" title="RRSIG Resource Records">
<t>
The value of the signature field in the RRSIG RR
follow the RSASSA-PKCS1-v1_5 signature scheme, and
is calculated as follows. The values for the RDATA
fields that precede the signature data are
specified in RFC 4034 <xref target="RFC4034" />.
</t>
<t>
hash = SHA-XXX(data)
</t>
<t>
Where XXX is either 256 or 512, depending on the
algorithm used.
</t>
<t>
signature = ( 00 | 01 | FF* | 00 | prefix | hash )
** e (mod n)
</t>
<t>
Where SHA-XXX is the message digest algorithm as
specified in FIPS PUB 180-2
<xref target="FIPS.180-2.2002"/>, "|" is
concatenation, "00", "01", "FF" and "00" are fixed octets
of corresponding hexadecimal value, "e" is the
private exponent of the signing RSA key, and "n" is
the public modulus of the signing key. The FF octet
MUST be repeated the maximum number of times so
that the total length of the signature equals the
length of the modulus of the signer's public key
("n"). "data" is the data of the resource record
set that is signed, as specified in RFC 4034
<xref target="RFC4034"/>.
</t>
<t>
The "prefix" is intended to make the use of
standard cryptographic libraries easier. These
specifications are taken directly from the
specification of EMSA-PKCS1-v1_5 encoding in PKCS
#1 v2.1 section 9.2 <xref target="RFC3447"/>. The
prefixes for the different algorithms are specified
below.
</t>
<section anchor="rrsig-sha256" title="RSA/SHA-256 RRSIG Resource Records">
<t>
RSA/SHA-256 signatures are stored in the DNS using
RRSIG resource records (RRs) with algorithm number
{TBA1} for use with NSEC, or {TBA2} for use with
NSEC3.
</t>
<t>
The prefix is the ASN.1 BER SHA-256 algorithm
designator prefix as specified in PKCS #1 v2.1
<xref target="RFC3447"/>:
</t>
<t>
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05
00 04 20
</t>
</section>
<section anchor="rrsig-sha512" title="RSA/SHA-512 RRSIG Resource Records">
<t>
RSA/SHA-512 signatures are stored in the DNS using
RRSIG resource records (RRs) with algorithm number
{TBA3} for use with NSEC, or {TBA4} for use with NSEC3.
</t>
<t>
The prefix is the ASN.1 BER SHA-512 algorithm
designator prefix as specified in PKCS #1 v2.1
<xref target="RFC3447"/>:
</t>
<t>
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05
00 04 40
</t>
</section>
</section>
<section anchor="deployment" title="Deployment Considerations">
<section anchor="keysizes" title="Key Sizes">
<t>
Apart from prohibiting RSA/SHA-512 signatures smaller
than 1024 bytes, this document will not specify what
size of keys to use. That is more an operational
issue and depends largely on the environment and
intended use. Some good starting points might be
DNSSEC Operational Practises
<xref target="RFC4641"/>, section 3.5, and NIST SP
800-57 Part 1 <xref target="NIST800-57-part1"/> and
Part 3 <xref target="NIST800-57-part3"/>.
</t>
</section>
<section anchor="sigsizes" title="Signature Sizes">
<t>
In this family of signing algorithms, the size of
signatures is related to the size of the key, and not
the hashing algorithm used in the signing
process. Therefore, RRSIG resource records produced
with RSA/SHA256 or RSA/SHA512 shall have the same size
as those produced with RSA/SHA1, if the keys have the
same length.
</t>
</section>
</section>
<section anchor="implementation" title="Implementation Considerations">
<t>
DNSSEC aware implementations SHOULD be able to
support RRSIG resource records with the RSA/SHA-2
algorithms.
</t>
<t>
If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource
records are available for a certain RRset, with a
secure path to their keys, the validator SHOULD
ignore the SHA-1 signature. If the RSA/SHA-2
signature does not verify the data, and the
RSA/SHA-1 signature does, the validator SHOULD mark
the data with the security status from the RSA/SHA-2
signature.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA has not yet assigned an algorithm number for
RSA/SHA-256 and RSA/SHA-512.
</t>
<t>
The algorithm list from RFC 4034 Appendix A.1
<xref target="RFC4034"/> is extended with the
following entries:
</t>
<figure>
<artwork><![CDATA[
Zone
Value Algorithm [Mnemonic] Signing References Status
----- ----------- ----------- ------- ----------- --------
{TBA1} RSA/SHA-256 RSASHA256 y {this memo} OPTIONAL
{TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} OPTIONAL
{TBA3} RSA/SHA-512 RSASHA512 y {this memo} OPTIONAL
{TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} OPTIONAL
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<section anchor="security_sha1_vs_sha2" title="SHA-1 versus SHA-2 Considerations for RRSIG Resource Records">
<t>
Users of DNSSEC are encouraged to deploy
SHA-2 as soon as software implementations
allow for it. SHA-2 is widely believed to
be more resilient to attack than SHA-1, and
confidence in SHA-1's strength is being eroded
by recently-announced attacks. Regardless of
whether or not the attacks on SHA-1 will
affect DNSSEC, it is believed (at the time of
this writing) that SHA-2 is the better
choice for use in DNSSEC records.
</t>
<t>
SHA-2 is considered sufficiently strong for the
immediate future, but predictions about future
development in cryptography and cryptanalysis are
beyond the scope of this document.
</t>
<t>
The signature scheme RSASSA-PKCS1-v1_5 is chosen
to match the one used for RSA/SHA-1
signatures. This should ease implementation of
the new hashing algorithms in DNSSEC software.
</t>
</section>
<section anchor="downgrade_attacks" title="Signature Type Downgrade Attacks">
<t>
Since each RRset MUST be signed with each
algorithm present in the DNSKEY RRset at the
zone apex (see <xref target="RFC4035"/>
Section 2.2), a malicious party cannot filter
out the RSA/SHA-2 RRSIG, and force the
validator to use the RSA/SHA-1 signature if
both are present in the zone. Together with
the implementation considerations from
<xref target="implementation"/> of this
document, this provides resilience against
algorithm downgrade attacks, if the validator
supports RSA/SHA-2.
</t>
</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>
This document is a minor extension to RFC 4034
<xref target="RFC4034"/>. Also, we try to follow
the documents RFC 3110 <xref target="RFC3110"/> and
RFC 4509 <xref target="RFC4509" /> for
consistency. The authors of and contributors to
these documents are gratefully acknowledged for
their hard work.
</t>
<t>
The following people provided additional feedback
and text: Jaap Akkerhuis, Roy Arends, Rob Austein,
Miek Gieben, Alfred Hoenes, Michael St. Johns,
Scott Rose and Wouter Wijngaards.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC4033'>
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
</front>
<seriesInfo name='RFC' value='4033' />
<format type='TXT' octets='52445' target='ftp://ftp.isi.edu/in-notes/rfc4033.txt' />
</reference>
<reference anchor='RFC4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' /></front>
<seriesInfo name='RFC' value='4034' />
<format type='TXT' octets='63879' target='ftp://ftp.isi.edu/in-notes/rfc4034.txt' />
</reference>
<reference anchor='RFC4035'>
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' /></front>
<seriesInfo name='RFC' value='4035' />
<format type='TXT' octets='130589' target='ftp://ftp.isi.edu/in-notes/rfc4035.txt' />
</reference>
<reference anchor='RFC3447'>
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'>
<organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
<organization /></author>
<date year='2003' month='February' /></front>
<seriesInfo name='RFC' value='3447' />
<format type='TXT' octets='143173' target='ftp://ftp.isi.edu/in-notes/rfc3447.txt' />
</reference>
<reference anchor="FIPS.180-2.2002">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="August" year="2002"/>
</front>
<seriesInfo name="FIPS" value="PUB 180-2"/>
</reference>
<reference anchor='RFC3110'>
<front>
<title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
<organization /></author>
<date year='2001' month='May' /></front>
<seriesInfo name='RFC' value='3110' />
<format type='TXT' octets='14587' target='ftp://ftp.isi.edu/in-notes/rfc3110.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="SCHNEIER-1996">
<front>
<title>
Applied Cryptography Second Edition: protocols,
algorithms, and source code in C
</title>
<author initials="B." surname="Schneier" fullname="Bruce Schneier">
<organization /></author>
<date year="1996" />
</front>
<seriesInfo name="Wiley and Sons" value=""/>
<seriesInfo name="ISBN" value="0-471-11709-9"/>
</reference>
<reference anchor='RFC4509'>
<front>
<title> Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</title>
<author initials='W.' surname='Hardaker' fullname='Wes Hardaker'>
<organization /></author>
<date year='2006' month='May' /></front>
<seriesInfo name='RFC' value='4509' />
<format type='TXT' octets='63879' target='ftp://ftp.isi.edu/in-notes/rfc4059.txt' />
</reference>
<reference anchor='RFC4641'>
<front>
<title>DNSSEC Operational Practices</title>
<author initials='O.' surname='Kolkman' fullname='O. Kolkman'>
<organization /></author>
<author initials='R.' surname='Gieben' fullname='R. Gieben'>
<organization /></author>
<date year='2006' month='September' />
</front>
<seriesInfo name='RFC' value='4641' />
<format type='TXT' octets='79894' target='ftp://ftp.isi.edu/in-notes/rfc4641.txt' />
</reference>
<reference anchor='NIST800-57-part1'>
<front>
<title>Recommendations for Key Management Part 1: General</title>
<author initials='E.' surname='Barker' fullname='E. Barker'>
<organization/>
</author>
<author initials='W.' surname='Barker' fullname='W. Barker'>
<organization/>
</author>
<author initials='W.' surname='Burr' fullname='W. Burr'>
<organization/>
</author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization/>
</author>
<author initials='M.' surname='Smid' fullname='M. Smid'>
<organization/>
</author>
<date year='2007' month='March'/>
</front>
<seriesInfo name='NIST SP' value='800-57 Part 1' />
</reference>
<reference anchor='NIST800-57-part3'>
<front>
<title>Recommendations for Key Management Part 3: Application-Specific Key Guidance</title>
<author initials='E.' surname='Barker' fullname='E. Barker'>
<organization/>
</author>
<author initials='W.' surname='Barker' fullname='W. Barker'>
<organization/>
</author>
<author initials='W.' surname='Burr' fullname='W. Burr'>
<organization/>
</author>
<author initials='A.' surname='Jones' fullname='A. Jones'>
<organization/>
</author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization/>
</author>
<author initials='M.' surname='Smid' fullname='M. Smid'>
<organization/>
</author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization/>
</author>
<date year='2007' month='March'/>
</front>
<seriesInfo name='NIST SP' value='800-57 Part 3' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:08 |