draft-ietf-dnsop-algorithm-update-03.txt   draft-ietf-dnsop-algorithm-update-04.txt 
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Obsoletes: 6944 (if approved) O. Sury Obsoletes: 6944 (if approved) O. Sury
Intended status: Standards Track Internet Systems Consortium Intended status: Standards Track Internet Systems Consortium
Expires: April 26, 2019 October 23, 2018 Expires: April 26, 2019 October 23, 2018
Algorithm Implementation Requirements and Usage Guidance for DNSSEC Algorithm Implementation Requirements and Usage Guidance for DNSSEC
draft-ietf-dnsop-algorithm-update-03 draft-ietf-dnsop-algorithm-update-04
Abstract Abstract
The DNSSEC protocol makes use of various cryptographic algorithms in The DNSSEC protocol makes use of various cryptographic algorithms in
order to provide authentication of DNS data and proof of non- order to provide authentication of DNS data and proof of non-
existence. To ensure interoperability between DNS resolvers and DNS existence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidelines to ensure that there implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements document defines the current algorithm implementation requirements
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4
3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4
3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7 3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Operational Considerations . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 7
6. Implementation Report . . . . . . . . . . . . . . . . . . . . 7 6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8
6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8 6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The DNSSEC signing algorithms are defined by various RFCs, including The DNSSEC signing algorithms are defined by various RFCs, including
[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080]. [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080].
DNSSEC is used to provide authentication of data. To ensure DNSSEC is used to provide authentication of data. To ensure
interoperability, a set of "mandatory-to-implement" DNSKEY algorithms interoperability, a set of "mandatory-to-implement" DNSKEY algorithms
are defined. This document obsoletes [RFC6944]. are defined. This document obsoletes [RFC6944].
1.1. Updating Algorithm Implementation Requirements and Usage Guidance 1.1. Updating Algorithm Implementation Requirements and Usage Guidance
skipping to change at page 5, line 26 skipping to change at page 5, line 26
RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not
seen wide deployment, but there are some deployments hence DNSSEC seen wide deployment, but there are some deployments hence DNSSEC
Validation MUST implement RSASHA512 to ensure interoperability. Validation MUST implement RSASHA512 to ensure interoperability.
There is no significant difference in cryptographics strength between There is no significant difference in cryptographics strength between
RSASHA512 and RSASHA256, therefore it is discouraged to use RSASHA512 and RSASHA256, therefore it is discouraged to use
RSASHA512, as it will only make deprecation of older algorithms RSASHA512, as it will only make deprecation of older algorithms
harder. People that wish to use a cryptographically stronger harder. People that wish to use a cryptographically stronger
algorithm should switch to elliptic curve cryptography algorithms. algorithm should switch to elliptic curve cryptography algorithms.
ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012 ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012
in [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use in [RFC7091]. The GOST R 34.10-2012 hasn't been standardized for use
in DNSSEC. in DNSSEC.
ECDSAP256SHA256 provides more cryptographic strength with a shorter ECDSAP256SHA256 provides more cryptographic strength with a shorter
signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256 signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256
has been widely deployed and therefore it is now at MUST level for has been widely deployed and therefore it is now at MUST level for
both validation and signing. It is RECOMMENDED to use deterministic both validation and signing. It is RECOMMENDED to use deterministic
digital signature generation procedure of the ECDSA ([RFC6979]) when digital signature generation procedure of the ECDSA ([RFC6979]) when
implementing ECDSAP256SHA256 (and ECDSAP384SHA384). implementing ECDSAP256SHA256 (and ECDSAP384SHA384).
ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but
skipping to change at page 6, line 43 skipping to change at page 6, line 43
NULL is a special case, see [RFC8078] NULL is a special case, see [RFC8078]
SHA-1 is still in wide use for DS records, so validators MUST SHA-1 is still in wide use for DS records, so validators MUST
implement validation, but it is NOT RECOMMENDED for use in generating implement validation, but it is NOT RECOMMENDED for use in generating
new DS and CDS records. (See Operational Considerations for caveats new DS and CDS records. (See Operational Considerations for caveats
when upgrading from SHA-1 to SHA-256 DS Algorithm.) when upgrading from SHA-1 to SHA-256 DS Algorithm.)
SHA-256 is in wide use and considered strong. SHA-256 is in wide use and considered strong.
GOST R 34.11-94 has been deprecated by [RFC6986]. GOST R 34.11-94 has been superseded by GOST R 34.11-2012 in
[RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use in
DNSSEC.
SHA-384 shares the same properties as SHA-256, but offers a modest SHA-384 shares the same properties as SHA-256, but offers a modest
security advantage over SHA-384 (384-bits of strength versus security advantage over SHA-384 (384-bits of strength versus
256-bits). For most applications of DNSSEC, SHA-256 should be 256-bits). For most applications of DNSSEC, SHA-256 should be
satisfactory and robust for the foreseeable future, and is therefore satisfactory and robust for the foreseeable future, and is therefore
recommended for DS and CDS records. While it is unlikely for a recommended for DS and CDS records. While it is unlikely for a
DNSSEC use case requiring 384-bit security strength to arise, SHA-384 DNSSEC use case requiring 384-bit security strength to arise, SHA-384
is provided for such applications and it MAY be used for generating is provided for such applications and it MAY be used for generating
DS and CDS records in these cases. DS and CDS records in these cases.
skipping to change at page 10, line 9 skipping to change at page 10, line 14
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
Hash Function", RFC 6986, DOI 10.17487/RFC6986, August Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
2013, <https://www.rfc-editor.org/info/rfc6986>. 2013, <https://www.rfc-editor.org/info/rfc6986>.
[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>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>. <https://www.rfc-editor.org/info/rfc7344>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583, "DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015, DOI 10.17487/RFC7583, October 2015,
<https://www.rfc-editor.org/info/rfc7583>. <https://www.rfc-editor.org/info/rfc7583>.
 End of changes. 7 change blocks. 
7 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/