idnits 2.17.1 draft-osterweil-dane-ent-email-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2014) is 3530 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Osterweil 3 Internet-Draft Verisign Labs 4 Intended status: Informational S. Rose 5 Expires: February 27, 2015 D. Montgomery 6 NIST 7 August 26, 2014 9 Enterprise Requirements for Secure Email Key Management 10 draft-osterweil-dane-ent-email-reqs-00 12 Abstract 14 Individuals and organizations have expressed a wish to have the 15 ability to send encrypted and/or digitally signed email end-to-end. 16 One key obstacle to end-to-end email security is the difficulty in 17 discovering, obtaining, and validating email credentials across 18 administrative domains. This document addresses foreseeable adoption 19 obstacles for DANE's cryptographic key management for email in 20 enterprises, and outlines requirements. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 27, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements for Both . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements for Authorities . . . . . . . . . . . . . . . . . 4 60 4. Requirements for Relying Parties . . . . . . . . . . . . . . . 5 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The management of security protections for email constituencies can 70 vary by organization and by type of organization. Some organizations 71 can have large sets of users with prescribed controls and policies, 72 some may have a lot of churn in their users, and there are many other 73 ways in which deployments may differ. 75 As a result of the variability of deployments, aligning key 76 management semantics with the behaviors of email users (and their 77 organizations) can be an important differentiator when administrators 78 choose a solution in which to invest. Designs and cryptographic 79 protocols that do not fit the requirements of users run the risk that 80 deployments may falter and/or may not gain traction. 82 This document addresses foreseeable requirements for DANE's 83 cryptographic key management for email in enterprises, and outlines 84 requirements. This document generally categorizes requirements as 85 being relevant to the domain authorities, the Relying Parties (RPs), 86 or both. In the following text, "domain authorities" refers to the 87 owners of a given domain, which may not necessarily be the operators 88 of the authoritative DNS servers for the zone(s) that make up the 89 domain. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Requirements for Both 99 REQ-1 Credentials stored can be either entire credential (i.e. the 100 key/certificate) or one-way hash of the credential. 102 Intuition: This can reduce the size of DNS responses. 104 REQ-2 The Protocol MUST be able to handle the use of DNS redirection 105 via CNAME/DNAME and wildcards. 107 Intuition: Managing user domain names may be a different 108 cardinality than number of S/MIME certificates. For 109 example, if the domain's users employ the same certificate 110 for both digital signature and encryption, a DNAME record 111 enables a single Resource Record (RR) for each user. 113 3. Requirements for Authorities 115 REQ-3 The protocol MUST support incremental rollout of DANE-centric 116 cryptographic protections, whereby not all users in an 117 enterprise may be cut over to a DANE solution at the same 118 time and MUST be backwards compatible 120 Intuition: Enterprise operations may wish be able to 121 enroll subsets of all of their users in a DANE 122 architecture without disrupting existing email 123 cryptographic services for all users. 125 REQ-4 The protocol MUST have the ability to either scope a 126 Certification Authority (CA) or local Trust Anchor (TA) in 127 use for a given domain. 129 Intuition: Enterprises may issue certificates from a TA 130 and prefer to authorize that certificate in DNS (instead 131 of End Entity certificates for every user). 133 REQ-5 The protocol SHOULD have the ability to signal that a 134 particular key/certificate is no longer to be trusted or is 135 revoked. 137 Intuition: Allows default TA authorizations to be 138 overridden by revocation. 140 REQ-6 The protocol SHOULD have the ability to signal that a 141 particular email address is not (or no longer) a valid sender 142 for the given domain. 144 Intuition: Allows for authenticated denial of existence 145 of a network identity. 147 REQ-7 The protocol MUST allow for separate management, publication, 148 and learning of keys that are used for signing versus 149 encryption. 151 Intuition: Separating, scaling, delegating, and general 152 management for different keys in different ways and in 153 different branches of the DNS allows administrators to 154 manage different material in different systems if needed. 156 REQ-8 The protocol MUST have the ability to delegate authority for 157 user names. 159 Intuition: Some enterprises may wish to use a service 160 provider. 162 REQ-9 The protocol MUST have the ability to manage keys in 163 different ways for different user names. 165 Intuition: Not all members of a medium/large enterprise 166 may be migrated onto a DANE system overnight, and must 167 operate alongside current email key management. This 168 could include users that use a different email security 169 protocol. 171 REQ-10 The protocol MUST have the ability to signal that a given 172 network identity (or entire zone) only sends digitally signed 173 messages. 175 Intuition: A domain owner may wish to signal that their 176 email security policy is to sign all outgoing message so 177 a receiver can infer an unsigned message is likely a 178 phishing attempt. 180 4. Requirements for Relying Parties 182 REQ-11 Key material for DANE-enabled email users MUST be verifiably 183 discoverable and learnable using just an email address. 185 Intuition: Email addresses are all the RP has, but may 186 point to external management systems. 188 REQ-12 The protocol SHOULD have the ability to provide opportunistic 189 encryption at the user's discretion. 191 Intuition: Compliance controls (for example) may mandate 192 the encryption of all messages under certain 193 circumstances. 195 REQ-13 The protocol MUST support default verification configurations 196 (such as enterprise TA or stapling) with user-specific 197 overrides. Overrides MUST include specifying specific 198 cryptographic information for specific users and disallowing 199 users (either specific cryptographic or entirely). 201 REQ-14 The protocol MUST be resistant to downgrade attacks targeting 202 the DNS response. 204 Intuition: If DNSSEC is stripped, the protocol MUST alert 205 the user or refuse to send an unencrypted email message. 207 REQ-15 The protocol MUST provide separate semantics to discover 208 certificates that are used for specific purposes. 210 Intuition: keep DNS response size minimal. 212 REQ-16 Encryption keys MUST be discoverable separately from 213 signature keys. Possible means includes (but not limited to) 214 naming conventions, sub-typing or unique RR types for each 215 use 217 Intuition: Not all certificates for a user may be needed 218 for all circumstances. Fetching them separately can be a 219 management, a scaling, or even a security concern. 221 5. Acknowledgements 223 TBD 225 6. IANA Considerations 227 This document only discusses requirements for publishing and querying 228 for security credentials used in email. No new IANA actions are 229 required in this document, but specifications addressing these 230 requirements may have IANA required actions. 232 This section should be removed in final publication. 234 7. Security Considerations 236 The motivation for this document is to outline requirements needed to 237 facilitate the secure publication and learning of cryptographic keys 238 for email, using DANE semantics. There are numerous documents that 239 more generally address security considerations for email. By 240 contrast, this document is not proposing a protocol or any facilities 241 that need to be secured. Instead, these requirements are intended to 242 inform security considerations in follow-on works. 244 8. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 Authors' Addresses 251 Eric Osterweil 252 Verisign Labs 253 Reston, VA 254 US 256 Email: 258 Scott Rose 259 NIST 260 100 Bureau Dr. 261 Gaithersburg, MD 20899 262 US 264 Email: scottr@nist.gov 266 Doug Montgomery 267 NIST 268 100 Bureau Dr. 269 Gaithersburg, MD 20899 270 US 272 Email: dougm@nist.gov