DNSSEC as it relates to the FISMA controls

Note: This is not meant to be a FISMA tutorial, nor is any of this information guaranteed to be 100% accurate. This is only meant to be a guide and collection of pointers to help a DNS administrator who needs to meet one or more FISMA controls with regards to the DNS protocol – there may be other controls that apply to the system host and/or institutional policies and procedures that also apply. Please see the NIST FISMA Implementation Project webpage for more detailed information.

The Federal Information Security Management Act (FISMA) (Title III of the E-Government Act) requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

At its heart is FIPS 199: Standards for Security Categorization of Federal Information and Information Systems which lays out the three categories for all Federal IT systems: Low, Moderate, and High and FIPS 200: Minimum Security Requirements for Federal Information and Information Systems which lays out the minimum requirements for Federal IT systems based on a risk-based process of selecting security controls. The individual controls that apply for each category are listed in NIST Special Publication 800-53 (revision 2): Recommended Security Controls for Federal Systems. Of these, four controls relate to lookup services (i.e. DNS) in particular:

• SC-8: Transition Integrity

• SC-20: Secure Name/Address Resolution Service (Authoritative Source)

• SC-21: Secure Name/Address Resolution Service (Recursive or Caching Service)

• SC-22: Architecture and Provisioning for Name/Address Resolution Service

Checking DNS Related FISMA Controls

There is another guideance document issued as part of the FISMA controls: NIST Special Publication 800-53A: Guide for Assessing the Security Controls in Federal Information Systems. This guide provides comprehensive assessment procedures for all security controls in NIST Special Publication 800-53 (as amended) and important guidance for federal agencies in building effective security assessment plans. Like NIST SP800-53r2, this guide breaks down the assessment procedures for each security control listed in NIST SP800-53r2 and gives guidance for checks depending on the control and security category of the system.

What about NIST Special Publication 800-57?

NIST Special Publication 800-57: Recommendations for Key Management is a three part publication that gives guidance for cryptographic key sizes base on intended use, future security requirements and protocol use. The first two parts of this Special Publication have been released. The third part will give guidance for specific application use including DNSSEC. As of the time of writing, part three of NIST SP800-57 is still in the editing phase and has not been released for public comments.

NIST Special Publication 800-57 is not listed as an official FISMA guidance document. However, the purpose of the publication and its contents cover Federal IT regulations with regard to cryptographic key sizes for various applications and a road map for future minimum security requirements. It would be a good idea for all Federal IT administrators to consult NIST SP800-57 when generating cryptographic keys for a particular application. The first part of SP800-57 has a general road map for key sizes that can be used to determine DNSSEC key sizes. For use in generating digital signatures, there is currently a requirement for 80 bit strong security, with 112 by 2010 (meaning the number of bits an attacker would have to correctly guess to launch an attack).

As of the time of writing, there is no support for RSA/SHA-256 or DSA/SHA-256 in any DNSSEC implementation. This is expected to change as the use of the SHA-2 suite of hashes is currently being specified through the IETF standards process. Once the use of SHA-256 with RSA (and DSA) is specified, administrators should plan to upgrade their server implementations to those that support the new algorithm suite. It is also not known if DSA will be specified with any of the SHA-2 suite, or only RSA.

The same could be said about the use of Elliptic Curve Cryptography in DNSSEC. There is some support for the use of ECC in various protocols because of features that make it appealing: smaller key sizes (compared to RSA) that provide the same strength, easier to generate keys, etc. However there is little demand to get ECC specified for use with DNSSEC due to the potential cost to perform signature verification (done online) compared to currently deployed algorithms. This attitude may change if new ECC implementations become widely available or a potential flaw is found in deployed algorithms.

A zone administrator should not immediately migrate to a new algorithm suite (RSA/SHA-256 or ECC/SHA-256) without a transition period when both the new and old algorithm suites are in use. This is for backwards compatibility with clients (DNSSEC validators) that have not been upgraded to understand the newly defined algorithm suite. During this time, older clients will continue to validate signatures using the older algorithm until they are upgraded and can validate the newly deployed algorithm suite. A more detailed guide (draft status) can be found here but others may be available as well.

Questions or comments should be sent to proj-dnssec@antd.nist.gov