Enterprise Requirements for Secure Email Key Management

The management of security protections for email constituencies can vary by organization and by type of organization. Some organizations can have large sets of users with prescribed controls and policies, some may have a lot of churn in their users, and there are many other ways in which deployments may differ. As a result of the variability of deployments, aligning key management semantics with the behaviors of email users (and their organizations) can be an important differentiator when administrators choose a solution in which to invest. Designs and cryptographic protocols that do not fit the requirements of users run the risk that deployments may falter and/or may not gain traction. This document addresses foreseeable requirements for DANE's cryptographic key management for email in enterprises, and outlines requirements. This document generally categorizes requirements as being relevant to the domain authorities, the Relying Parties (RPs), or both. In the following text, "domain authorities" refers to the owners of a given domain, which may not necessarily be the operators of the authoritative DNS servers for the zone(s) that make up the domain.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Credentials stored can be either entire credential (i.e. the key/certificate) or one-way hash of the credential. Intuition: This can reduce the size of DNS responses. The Protocol MUST be able to handle the use of DNS redirection via CNAME/DNAME and wildcards. Intuition: Managing user domain names may be a different cardinality than number of S/MIME certificates. For example, if the domain's users employ the same certificate for both digital signature and encryption, a DNAME record enables a single Resource Record (RR) for each user.

The protocol MUST support incremental rollout of DANE-centric cryptographic protections, whereby not all users in an enterprise may be cut over to a DANE solution at the same time and MUST be backwards compatible Intuition: Enterprise operations may wish be able to enroll subsets of all of their users in a DANE architecture without disrupting existing email cryptographic services for all users. The protocol MUST have the ability to either scope a Certification Authority (CA) or local Trust Anchor (TA) in use for a given domain. Intuition: Enterprises may issue certificates from a TA and prefer to authorize that certificate in DNS (instead of End Entity certificates for every user). The protocol SHOULD have the ability to signal that a particular key/certificate is no longer to be trusted or is revoked. Intuition: Allows default TA authorizations to be overridden by revocation. The protocol SHOULD have the ability to signal that a particular email address is not (or no longer) a valid sender for the given domain. Intuition: Allows for authenticated denial of existence of a network identity. The protocol MUST allow for separate management, publication, and learning of keys that are used for signing versus encryption. Intuition: Separating, scaling, delegating, and general management for different keys in different ways and in different branches of the DNS allows administrators to manage different material in different systems if needed. The protocol MUST have the ability to delegate authority for user names. Intuition: Some enterprises may wish to use a service provider. The protocol MUST have the ability to manage keys in different ways for different user names. Intuition: Not all members of a medium/large enterprise may be migrated onto a DANE system overnight, and must operate alongside current email key management. This could include users that use a different email security protocol. The protocol MUST have the ability to signal that a given network identity (or entire zone) only sends digitally signed messages. Intuition: A domain owner may wish to signal that their email security policy is to sign all outgoing message so a receiver can infer an unsigned message is likely a phishing attempt.

Key material for DANE-enabled email users MUST be verifiably discoverable and learnable using just an email address. Intuition: Email addresses are all the RP has, but may point to external management systems. The protocol SHOULD have the ability to provide opportunistic encryption at the user's discretion. Intuition: Compliance controls (for example) may mandate the encryption of all messages under certain circumstances. The protocol MUST support default verification configurations (such as enterprise TA or stapling) with user-specific overrides. Overrides MUST include specifying specific cryptographic information for specific users and disallowing users (either specific cryptographic or entirely). The protocol MUST be resistant to downgrade attacks targeting the DNS response. Intuition: If DNSSEC is stripped, the protocol MUST alert the user or refuse to send an unencrypted email message. The protocol MUST provide separate semantics to discover certificates that are used for specific purposes. Intuition: keep DNS response size minimal. Encryption keys MUST be discoverable separately from signature keys. Possible means includes (but not limited to) naming conventions, sub-typing or unique RR types for each use Intuition: Not all certificates for a user may be needed for all circumstances. Fetching them separately can be a management, a scaling, or even a security concern.

TBD

This document only discusses requirements for publishing and querying for security credentials used in email. No new IANA actions are required in this document, but specifications addressing these requirements may have IANA required actions. This section should be removed in final publication.

The motivation for this document is to outline requirements needed to facilitate the secure publication and learning of cryptographic keys for email, using DANE semantics. There are numerous documents that more generally address security considerations for email. By contrast, this document is not proposing a protocol or any facilities that need to be secured. Instead, these requirements are intended to inform security considerations in follow-on works.