idnits 2.17.1 draft-hallambaker-dkimpolicy-00.txt: -(56): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 135 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RRC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6497 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RRC 2119' on line 64 looks like a reference -- Missing reference section? 'RFC 2119' on line 384 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft P. Hallam-Baker 3 Document: draft-hallambaker-dkimpolicy-00.txt VeriSign Inc. 4 Expires: December 2006 June 2006 6 Considerations for DKIM Policy Language 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 If we are going to change the current DKIM policy language as 33 deployed in any way including definition of a new DNS RR we should do 34 the job properly and define a layered infrastructure that is capable 35 of other uses. 37 Contents 39 Considerations for DKIM Policy Language.............................1 40 Status of this Memo...............................................1 41 Abstract..........................................................1 42 Contents............................................................2 43 1. Conventions used in this document................................2 44 2. Is change necessary?.............................................2 45 3. What is a Layered Infrastructure?................................3 46 3.1 What a Layered Architecture is Not............................4 47 3.2 Reusable Escape Mechanism.....................................4 48 3.3 Reusable Cryptography Attributes..............................5 49 3.4 Reusable Discovery Strategy...................................5 50 4. Next Steps.......................................................8 51 4.1 Attempt a Layered Definition of SSP...........................8 52 4.2 New RR Definitions Should Support Infrastructure, not DKIM....8 53 Notices.............................................................8 54 References..........................................................9 55 Acknowledgments.....................................................9 56 Authors� Addresses..................................................9 58 1. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119 [RRC 2119]. 65 2. 66 Is change necessary? 68 Sender Security Policy (SSP) appears to be an adequate basis for a 69 security policy to support the immediate needs of DKIM. It appears 70 that the email sender has sufficient scope to describe the 71 configuration of their outbound email authentication using the DKIM 72 message format and it is is clearly capable of extension to support 73 additional attributes that may be found to be necessary. 75 An entirely reasonable approach to supporting the policy needs of 76 DKIM is to simply adopt the SSP framework as is maintaining strict 77 backwards compatibility but making whatever minor adjustments as may 78 be found necessary. 80 The adoption of a new DNS Resource Record is not supported in any 81 existing DKIM infrastructure and thus represents an incompatible 82 change. 84 If however backwards compatibility is to be lost for any reason the 85 working group should reject the current SSP document which is 86 exclusively focused on DKIM and instead adopt a layered approach in 87 which the working group first defines a framework for expressing 88 general security policy and then defines the DKIM policy mechanism as 89 an instance of that framework. 91 DKIM is an important resource for managing email security. The lack 92 of robust, practical, ubiquitous email authentication is clearly the 93 most significant defect in the present email system. It is not 94 however the only security defect in the email system that needs to be 95 fixed. For many years large numbers of email servers have been 96 capable of supporting email exchange over TLS, without policy layer 97 support however this infrastructure is vulnerable to a downgrade 98 attack. The use of domain level S/MIME and PGP face the same problem. 100 The need for a policy layer integrated into the signaling system 101 represents a clear deficiency in the Internet infrastructure and is 102 one of the principal causes for many of the limitations that are felt 103 when using or administering Internet protocols. Most protocols 104 provide support for version numbers but as is widely acknowledged a 105 version number does little more than avoid unintended consequences 106 when a client attempts to connect to a server using an incompatible 107 protocol version. Administration of a transition from one protocol 108 version to another or from one protocol to a different one requires a 109 policy infrastructure. 111 The Internet is gradually acquiring a policy infrastructure and a 112 decision by the DKIM working group to decide to adopt or reject a 113 layered approach will have little impact on this process. A policy 114 infrastructure is already being developed to support Web Services, 115 the need to extend this framework to support REST or AJAX based 116 applications is inevitable. 118 Adopting a layered approach in DKIM will not change the fact of 119 policy infrastructure deployment but it may impact the consistency 120 and comprehensiveness of the infrastructure that evolves. A similar 121 effect was seen in the deployment of MX and SRV. The need to provide 122 fault tolerant service was felt first in email. Later it was realized 123 that this need was inherent in every Internet protocol and the SRV 124 record was defined. 126 3. 127 What is a Layered Infrastructure? 129 The principle of layered abstraction is a basic tool of network 130 design yet providing a definition of a layered abstraction is almost 131 challenging as designing one. 133 The statements we want to make for DKIM are instances of more general 134 requirements: 136 "Every email from example.com has a DKIM signature with 137 characteristics {x, y, z}" 138 "The example.com email server always offers STARTTLS with 139 charateristics {p, q}" 140 "http://example.com supports HTTP/2.0" 142 Instead of defining statements and syntax that are specific to DKIM 143 we should attempt to define policy statements in such a way that 144 encourages reuse whenever possible. 146 3.1 147 What a Layered Architecture is Not 149 Equally important is the definition of what a layered architecture is 150 not. The key to the design of a layered architecture is the 151 specification of a series of well defined abstractions and the 152 definition of the communication between those abstractions. 154 If the definition of the policy language requires constant recourse 155 to make changes to the DNS protocol the policy language framework is 156 broken. 158 The DNS is a large deployed infrastructure with a very specific task. 159 Changes to the DNS infrastructure to support deployment of a policy 160 infrastructure should be avoided if at all possible but are 161 acceptable for the purposes of deploying a policy infrastructure that 162 will serve multiple protocols. 164 What is not acceptable is a �policy infrastructure� where each policy 165 definition to support a new protocol requires changes to be made to 166 the DNS infrastructure. 168 3.2 169 Reusable Escape Mechanism 171 Clearly there is a strict limit to the detail that is practical 172 within the context of DNS publication of service configuration data, 173 clearly we do not want people entering war and peace into the DNS to 174 configure an email service. It is bad enough the fact that airline 175 check in assistants have to write novels while checking people in for 176 a flight from Boston to Washington without network administrators 177 attempting to write complex security policies into DNS configuration 178 files to be emitted as 500 byte DNS response messages. 180 Writing security policy should not be like writing a haiku: fitting a 181 complex idea into a tightly restricted form of expression. 183 There are two means of extension that might be employed. First the 184 policy mechanism might extend within the DNS itself using some form 185 of include directive similar to that defined in SenderID/SPF 186 framework. Alternatively the extension might be by means of an 187 arbitrary URL from which the full policy may be obtained. 189 If the extension mechanism is to be to an arbitrary URL it is 190 probably most appropriate to allow use of a richer, more expressive 191 syntax such as XML than the compact tag value encoding forms 192 generally considered more appropriate for use in the DNS. 194 3.3 195 Reusable Cryptography Attributes 197 A security policy is at root a statement that says that a certain 198 network principle shall always offer a certain minimum level of 199 security when making a communication. 201 For example 203 �example.com will always sign outgoing emails using a 204 minimum of SHA-1 and RSA1024� 206 �example.com will always offer STARTTLS in SMTP 207 transactions with a certificate validated via a cert 208 chain whose root cert has a SHA1 fingerprint of 209 Q282hd9213h23ey23== and offer a minimum of RSA 1024 210 and RC4� 212 It is clear that many of the attributes referenced in the above 213 policies will be generally applicable. For example IANA maintains a 214 registry of consistent names for cryptographic algorithms. 216 Note that the above policy statements need not exhaustively enumerate 217 every cryptographic algorithm that might be offered. If the email 218 server in the second example offers AES 128 it need not mention that 219 it also supports 3DES and AES 256. 221 It is however essential that each of the algorithms described be 222 offered in the form described. Otherwise there would be the 223 possibility of a downgrade through unacceptable upgrade attack where 224 a man in the middle inserts an offer of RSA 32768 knowing that it 225 will be rejected even though it is stronger than RSA 1024. 227 3.4 228 Reusable Discovery Strategy 230 The principle area in which the current SSP specification is 231 unsatisfactory is in the area of policy discovery. It appears that 232 unless a new RR is defined specifically for DKIM policy records that 233 it will be impossible to support the form of wildcarding we require 234 without resort to heuristics or exhaustive search strategies that may 235 facilitate denial of service attacks. 237 Definition of a new RR should be avoided if at all possible. 238 According to source code samples demonstrated by one of the leading 239 providers of the deployed base of DNS servers their product is not 240 capable of saving data associated with unknown RRs. Any configuration 241 changes made to the server by mechanisms such as the dynamic DNS 242 component which does support use of new RRs will thus be lost 243 whenever the service is stopped and restarted. 245 In the absence of proof that the DNS server vendor concerned engaged 246 in a deliberate lie it is prudent to assume that any deployment of 247 new DNS RRs has a significant infrastructure cost and should be 248 avoided unless absolutely necessary. 250 As we know the DNS wildcard scheme is not ideal for our purposes: 252 1: There is no way to specify a wildcard of the form 253 _prefix.*.example.com 255 2: The prefix *.example.com does not match host1.example.com if 256 there is any record defined for that node 258 The solution recommended by the DNSEXT Working Group members to the 259 first problem is to define a new DNS RR. 261 The second problem exists whether or not a new record is defined. The 262 only way to address this problem within the existing DNSSEC framework 263 is to add support at the DNS server level for synthetic wildcards. So 264 the admin enters a policy for ?.example.com which is expanded out to 265 create records for every host in example.com that does exist and does 266 not have a policy record otherwise defined. 268 The first problem is the hard one, one solution is to define a new 269 resource record. This is not sustainable as an infrastructure. Every 270 internet protocol will need a DNS policy record associated with it so 271 we would need to define 10,000 new RRs just to support existing 272 protocols. 274 A better solution is to define a record to act as the wildcard 275 record. The use of the PTR record is currently undefined for the 276 forward DNS and allows the needed information to be defined. 278 Alternatively a new record could be specified, but this would then 279 make implementations dependent on the deployment of DNS extensions. 281 The policy discovery strategy then becomes: 283 To discover the policy for DKIM at alice.example.com: 285 1) policy = lookup (TXT, "_dkim.alice.example.com") 286 IF policy <> NULL THEN RETURN policy 288 2) pointer = lookup (PTR, "alice.example.com") 289 IF pointer == NULL THEN RETURN NULL 291 3) policy = lookup (TXT, "_dkim." + pointer) 292 return policy 294 This strategy is guaranteed to always return in three steps without 295 exception and is 100% compatible with the deployed DNS infrastructure 296 with no known exceptions. 298 The strategy is can be applied to an arbitrary protocol and allows 299 for much simplified administration. In most networks the majority of 300 the host configurations are essentially identical. Only a few 301 machines that perform special roles such as mail handling or file 302 server support will require custom configuration. 304 The redirect strategy allows the administrator to define standard 305 network policy configurations, for example in an enterprise there 306 would probably be defined network policy configs for standard 307 desktops, standard laptops and developer machines. If necessary the 308 standard config may be overriden for individual domain names. 310 The redirect stategy does not depend on walking up the chain, finding 311 a zone cut or anything similar, it also overcomes a frequent 312 objection to such attempts, it is does not allow an unauthorized 313 intermediate DNS server to override policy definitions made by a 314 subordinate zone - except of course to the extent that it can do this 315 by changing the delegation and hijacking the entire zone. 317 A possible objection to the strategy is that it imposes new semantics 318 on the PTR record, a record which to date has only been defined for 319 use in the reverse DNS. Fortunately however the lack of defined 320 semantics outside the reverse DNS means that the only problem that 321 may occur in the forward DNS is that this use may collide with other 322 attempts to redefine PTR. 324 The issue of the reverse DNS is more complex. The most prudent course 325 might be to prohibit the use of PTR for policy redirection, yet the 326 semantics that are achieved through use of PTR appear to be exactly 327 what we might want such semantics to be. It is probably prudent to 328 simply note this apparent oddity and note that since email is not 329 sent from the reverse DNS zone it is unlikely to impact DKIM. 331 4. 332 Next Steps 334 4.1 335 Attempt a Layered Definition of SSP 337 We recommend that the DKIKM working group examine the possibility of 338 redefining the current SSP specification in terms of a layered model 339 where the policy infrastructure framework is separated from the 340 instance to support DKIM. 342 4.2 343 New RR Definitions Should Support Infrastructure, not DKIM 345 A previously noted a policy infrastructure should separate the 346 specific needs of DKIM from needs that are general to multiple 347 protocols. 349 If it is the case that a new RR definition is essential and it is not 350 possible to deploy DKIM in a manner that meets all the objectives of 351 DKIM within the capabilities of the legacy DNS then whatever RRs are 352 defined should be designed to support a policy infrastructure rather 353 than the specific DKIM protocol. 355 It is simply not acceptable or sustainable for all attempts to define 356 protocol policy records to be gated on a single IETF working group, 357 particularly one that will in any case be wound up as soon as the DNS 358 Security deployment is complete. There are many forums that define 359 Internet protocols and every protocol will require policy. 361 There are already far more unofficial definitions of DNS SRV entries 362 than there are official ones. Unless a realistic approach is adopted 363 that supports the principal of independent innovation once considered 364 the founding principle of the IETF as an institution. 366 Notices 368 Copyright (C) The Internet Society (2006). 370 This document is subject to the rights, licenses and restrictions 371 contained in BCP 78, and except as set forth therein, the authors 372 retain all their rights. 374 This document and the information contained herein are provided on an 375 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 376 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 377 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 378 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 379 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 380 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 382 References 384 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997 387 Acknowledgments 389 The author would like to acknowledge the contribution of Stephen 390 Farrell without whose insistence on writing it this document would 391 never have been written. 393 Authors� Addresses 395 Phillip Hallam-Baker 396 VeriSign Inc. 397 pbaker@verisign.com