NIST SP 800-177 Revision 1: “Trustworthy Email”

By / / Cryptography, Cybersecurity Articles, Messaging Security, Standards & Guidelines / 800-177, authentication, DKIM, DMARC, email, encryption, Messaging, NIST, SPF, TLS
Trustworthy Email

The National Institute of Standards and Technology (NIST) has released its Security Publication (SP) 800-177 Revision 1, that includes security recommendations for achieving “Trustworthy Email.”

SP 800-177 Rev 1 includes updated guidelines for securing email communications, such as SPF, DKIM, DMARC and TLS encryption protocols.

These protections provide better email spoofing and integrity protection, as well as enhanced encryption and authentication required to secure email systems.

An abstract of the Trustworthy Email standard document from the NIST website:

“This document gives recommendations and guidelines for enhancing trust in email. The primary audience includes enterprise email administrators, information security specialists and network managers. This guideline applies to federal IT systems and will also be useful for small or medium sized organizations. Technologies recommended in support of core Simple Mail Transfer Protocol (SMTP) and the Domain Name System (DNS) include mechanisms for authenticating a sending domain: Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain based Message Authentication, Reporting and Conformance (DMARC). Recommendations for email transmission security include Transport Layer Security (TLS) and associated certificate authentication protocols. Recommendations for email content security include the encryption and authentication of message content using S/MIME (Secure/Multipurpose Internet Mail Extensions) and associated certificate and key distribution protocols.”

The primary audience for the new Trustworthy Email SP 800-173 Rev 1 includes email administrators, security specialists and network managers.

A few of the notable recommendations from the document include SPF, DKIM and DMARC, among other email security best practices.

Sender Policy Framework (SPF)

SPF specifies which IP addresses are authorized to transmit email on behalf of domain. NIST says that organizations should deploy SPF with DNS security (or DNSSEC) for all DNS name servers. These protections will help ensure source authentication and integrity and protection of DNS data.

Why use SPF? SPF is designed to address phishing and spam sent by unauthorized senders.

Do you use any third parties for sending your email such as cloud providers? If you do, NIST recommends organizations make sure any email sent by those third parties will pass SPF checks.

For instance, the email administrators should include the IP addresses of third party email senders in the enterprise SPF policy statement RR.

Implement DKIM

DKIM, short for DomainKeys Identified Mail, provides a method for validating the domain name identity that is associated with an email through cryptographic authentication. In other words, email should be “signed” with a digital signature. Organizations should also use DKIM to detect spoofing and prevent phishing and email spam.

Currently, NIST recommends using DKIM with the following crypto key parameters: RSA/SHA-256 with 2048 bits and lifetime of 1-2 years. Also, the standard supports Edwards-curve Digital Signature Algorithm Curve 25519 (ed25519) with 256 bit key length.

Similar to SFP, organizations should also deploy DNSSEC.

In addition, mailing list software should verify DKIM signatures on incoming mail and re-sign outgoing email with needed DKIM signatures.

Also, mail sent to broadcast lists from “do not reply” or unmonitored mailboxes should also be signed with S/MIME signatures.

When using DKIM with cloud or contracted email services, organizations should generate a unique key pair for each third party or cloud service.

“No private key should be shared between contracted services or cloud instances,” NIST added.

Implement DMARC

DMARC, or Domain-based Message Authentication Reporting and Conformance, allows the email sending domain owner, such as your company, to specify how receivers can verify the authenticity of the sender organization’s email. In addition, DMARC helps your organization (or the receiver) handle email that fails to verify.

Also, DMARC basically adds a link between the domain of the sender with the authentication results for SPF and DKIM.

According to the SP 800-177 Rev 1 guidelines, the sending domain owners who deploy SPF and/or DKIM are recommended to publish a DMARC record. In other words, this DMARC record signals to mail receivers the disposition expected for messages purporting to originate from sender’s domain.

NIST also recommends that mail receivers should dispose of received messages according to sending domain’s published DMARC policy. Furthermore, organizations should also initiate failure reports according to sending domain’s DMARC policies.

Furthermore, SP 800-177 Rev 1 also includes additional guidance for email administrators. For instance, email administrators can learn how to better guard against email threats, protect email confidentiality, reduce spam email and end-user email security to name a few.

Protect email confidentiality

Organizations are highly recommended to migrate from TLS 1.1 to TLS 1.2 “with all practical speed” and to ensure email transferred between servers and end-to-end email is encrypted. See SP 800-52 for more information. On a related topic, PCI changed their deadlines and guidance last year to move to more secure protocols by 2018. However, they too still recommend new implementations use TLS 1.2. 

TLS capable  servers should prompt clients to invoke STARTTLS command (for SMTP) and also use S/MIME with a certificate signed by a known CA (preferred over OpenPGP).

Other useful guidance include blocking outbound port 25 (except for authorized mail servers) and block inbound port 25 (use firewalls and IDS to alert when an unauthorized hosts are accepting mail). 

End-user email security

NIST recommends IMAP and POP3 clients are used to connect to servers using TLS. Don’t forget to never connect with unencrypted TCP used for authentication with usernames and passwords.

Finally, crypto keys used for encrypting data in persistent storage (such as mailboxes) should be different from keys used for transmission of email messages.

Related Articles