Internet Draft P. Hallam-Baker Document: draft-hallambaker-pcon-00.txt VeriSign Inc. Expires: December 2006 June 2006 Considerations for DKIM Policy Language Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract If we are going to change the current DKIM policy language as deployed in any way including definition of a new DNS RR we should do the job properly and define a layered infrastructure that is capable of other uses. Hallam-Baker Expires December 2006 Page 1 Considerations for DKIM Policy Language June 2006 Contents Considerations for DKIM Policy Language.............................1 Status of this Memo...............................................1 Abstract..........................................................1 Contents............................................................2 1. Conventions used in this document................................2 2. Is change necessary?.............................................2 3. What is a Layered Infrastructure?................................3 3.1 What a Layered Architecture is Not............................4 3.2 Reusable Escape Mechanism.....................................4 3.3 Reusable Cryptography Attributes..............................5 3.4 Reusable Discovery Strategy...................................5 4. Next Steps.......................................................8 4.1 Attempt a Layered Definition of SSP...........................8 4.2 New RR Definitions Should Support Infrastructure, not DKIM....8 Notices.............................................................8 References..........................................................9 Acknowledgments.....................................................9 Authors’ Addresses..................................................9 1. Conventions used in this document 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 [RRC 2119]. 2. Is change necessary? Sender Security Policy (SSP) appears to be an adequate basis for a security policy to support the immediate needs of DKIM. It appears that the email sender has sufficient scope to describe the configuration of their outbound email authentication using the DKIM message format and it is is clearly capable of extension to support additional attributes that may be found to be necessary. An entirely reasonable approach to supporting the policy needs of DKIM is to simply adopt the SSP framework as is maintaining strict backwards compatibility but making whatever minor adjustments as may be found necessary. The adoption of a new DNS Resource Record is not supported in any existing DKIM infrastructure and thus represents an incompatible change. If however backwards compatibility is to be lost for any reason the working group should reject the current SSP document which is Hallam-Baker Expires August 2006 Page 2 Considerations for DKIM Policy Language June 2006 exclusively focused on DKIM and instead adopt a layered approach in which the working group first defines a framework for expressing general security policy and then defines the DKIM policy mechanism as an instance of that framework. DKIM is an important resource for managing email security. The lack of robust, practical, ubiquitous email authentication is clearly the most significant defect in the present email system. It is not however the only security defect in the email system that needs to be fixed. For many years large numbers of email servers have been capable of supporting email exchange over TLS, without policy layer support however this infrastructure is vulnerable to a downgrade attack. The use of domain level S/MIME and PGP face the same problem. The need for a policy layer integrated into the signaling system represents a clear deficiency in the Internet infrastructure and is one of the principal causes for many of the limitations that are felt when using or administering Internet protocols. Most protocols provide support for version numbers but as is widely acknowledged a version number does little more than avoid unintended consequences when a client attempts to connect to a server using an incompatible protocol version. Administration of a transition from one protocol version to another or from one protocol to a different one requires a policy infrastructure. The Internet is gradually acquiring a policy infrastructure and a decision by the DKIM working group to decide to adopt or reject a layered approach will have little impact on this process. A policy infrastructure is already being developed to support Web Services, the need to extend this framework to support REST or AJAX based applications is inevitable. Adopting a layered approach in DKIM will not change the fact of policy infrastructure deployment but it may impact the consistency and comprehensiveness of the infrastructure that evolves. A similar effect was seen in the deployment of MX and SRV. The need to provide fault tolerant service was felt first in email. Later it was realized that this need was inherent in every Internet protocol and the SRV record was defined. 3. What is a Layered Infrastructure? The principle of layered abstraction is a basic tool of network design yet providing a definition of a layered abstraction is almost challenging as designing one. Hallam-Baker Expires August 2006 Page 3 Considerations for DKIM Policy Language June 2006 The statements we want to make for DKIM are instances of more general requirements: "Every email from example.com has a DKIM signature with characteristics {x, y, z}" "The example.com email server always offers STARTTLS with charateristics {p, q}" "http://example.com supports HTTP/2.0" Instead of defining statements and syntax that are specific to DKIM we should attempt to define policy statements in such a way that encourages reuse whenever possible. 3.1 What a Layered Architecture is Not Equally important is the definition of what a layered architecture is not. The key to the design of a layered architecture is the specification of a series of well defined abstractions and the definition of the communication between those abstractions. If the definition of the policy language requires constant recourse to make changes to the DNS protocol the policy language framework is broken. The DNS is a large deployed infrastructure with a very specific task. Changes to the DNS infrastructure to support deployment of a policy infrastructure should be avoided if at all possible but are acceptable for the purposes of deploying a policy infrastructure that will serve multiple protocols. What is not acceptable is a ‘policy infrastructure’ where each policy definition to support a new protocol requires changes to be made to the DNS infrastructure. 3.2 Reusable Escape Mechanism Clearly there is a strict limit to the detail that is practical within the context of DNS publication of service configuration data, clearly we do not want people entering war and peace into the DNS to configure an email service. It is bad enough the fact that airline check in assistants have to write novels while checking people in for a flight from Boston to Washington without network administrators attempting to write complex security policies into DNS configuration files to be emitted as 500 byte DNS response messages. Writing security policy should not be like writing a haiku: fitting a complex idea into a tightly restricted form of expression. Hallam-Baker Expires August 2006 Page 4 Considerations for DKIM Policy Language June 2006 There are two means of extension that might be employed. First the policy mechanism might extend within the DNS itself using some form of include directive similar to that defined in SenderID/SPF framework. Alternatively the extension might be by means of an arbitrary URL from which the full policy may be obtained. If the extension mechanism is to be to an arbitrary URL it is probably most appropriate to allow use of a richer, more expressive syntax such as XML than the compact tag value encoding forms generally considered more appropriate for use in the DNS. 3.3 Reusable Cryptography Attributes A security policy is at root a statement that says that a certain network principle shall always offer a certain minimum level of security when making a communication. For example ‘example.com will always sign outgoing emails using a minimum of SHA-1 and RSA1024’ ‘example.com will always offer STARTTLS in SMTP transactions with a certificate validated via a cert chain whose root cert has a SHA1 fingerprint of Q282hd9213h23ey23== and offer a minimum of RSA 1024 and RC4’ It is clear that many of the attributes referenced in the above policies will be generally applicable. For example IANA maintains a registry of consistent names for cryptographic algorithms. Note that the above policy statements need not exhaustively enumerate every cryptographic algorithm that might be offered. If the email server in the second example offers AES 128 it need not mention that it also supports 3DES and AES 256. It is however essential that each of the algorithms described be offered in the form described. Otherwise there would be the possibility of a downgrade through unacceptable upgrade attack where a man in the middle inserts an offer of RSA 32768 knowing that it will be rejected even though it is stronger than RSA 1024. 3.4 Reusable Discovery Strategy Hallam-Baker Expires August 2006 Page 5 Considerations for DKIM Policy Language June 2006 The principle area in which the current SSP specification is unsatisfactory is in the area of policy discovery. It appears that unless a new RR is defined specifically for DKIM policy records that it will be impossible to support the form of wildcarding we require without resort to heuristics or exhaustive search strategies that may facilitate denial of service attacks. Definition of a new RR should be avoided if at all possible. According to source code samples demonstrated by one of the leading providers of the deployed base of DNS servers their product is not capable of saving data associated with unknown RRs. Any configuration changes made to the server by mechanisms such as the dynamic DNS component which does support use of new RRs will thus be lost whenever the service is stopped and restarted. In the absence of proof that the DNS server vendor concerned engaged in a deliberate lie it is prudent to assume that any deployment of new DNS RRs has a significant infrastructure cost and should be avoided unless absolutely necessary. As we know the DNS wildcard scheme is not ideal for our purposes: 1: There is no way to specify a wildcard of the form _prefix.*.example.com 2: The prefix *.example.com does not match host1.example.com if there is any record defined for that node The solution recommended by the DNSEXT Working Group members to the first problem is to define a new DNS RR. The second problem exists whether or not a new record is defined. The only way to address this problem within the existing DNSSEC framework is to add support at the DNS server level for synthetic wildcards. So the admin enters a policy for ?.example.com which is expanded out to create records for every host in example.com that does exist and does not have a policy record otherwise defined. The first problem is the hard one, one solution is to define a new resource record. This is not sustainable as an infrastructure. Every internet protocol will need a DNS policy record associated with it so we would need to define 10,000 new RRs just to support existing protocols. A better solution is to define a record to act as the wildcard record. The use of the PTR record is currently undefined for the forward DNS and allows the needed information to be defined. Hallam-Baker Expires August 2006 Page 6 Considerations for DKIM Policy Language June 2006 Alternatively a new record could be specified, but this would then make implementations dependent on the deployment of DNS extensions. The policy discovery strategy then becomes: To discover the policy for DKIM at alice.example.com: 1) policy = lookup (TXT, "_dkim.alice.example.com") IF policy <> NULL THEN RETURN policy 2) pointer = lookup (PTR, "alice.example.com") IF pointer == NULL THEN RETURN NULL 3) policy = lookup (TXT, "_dkim." + pointer) return policy This strategy is guaranteed to always return in three steps without exception and is 100% compatible with the deployed DNS infrastructure with no known exceptions. The strategy is can be applied to an arbitrary protocol and allows for much simplified administration. In most networks the majority of the host configurations are essentially identical. Only a few machines that perform special roles such as mail handling or file server support will require custom configuration. The redirect strategy allows the administrator to define standard network policy configurations, for example in an enterprise there would probably be defined network policy configs for standard desktops, standard laptops and developer machines. If necessary the standard config may be overriden for individual domain names. The redirect stategy does not depend on walking up the chain, finding a zone cut or anything similar, it also overcomes a frequent objection to such attempts, it is does not allow an unauthorized intermediate DNS server to override policy definitions made by a subordinate zone - except of course to the extent that it can do this by changing the delegation and hijacking the entire zone. A possible objection to the strategy is that it imposes new semantics on the PTR record, a record which to date has only been defined for use in the reverse DNS. Fortunately however the lack of defined semantics outside the reverse DNS means that the only problem that may occur in the forward DNS is that this use may collide with other attempts to redefine PTR. Hallam-Baker Expires August 2006 Page 7 Considerations for DKIM Policy Language June 2006 The issue of the reverse DNS is more complex. The most prudent course might be to prohibit the use of PTR for policy redirection, yet the semantics that are achieved through use of PTR appear to be exactly what we might want such semantics to be. It is probably prudent to simply note this apparent oddity and note that since email is not sent from the reverse DNS zone it is unlikely to impact DKIM. 4. Next Steps 4.1 Attempt a Layered Definition of SSP We recommend that the DKIKM working group examine the possibility of redefining the current SSP specification in terms of a layered model where the policy infrastructure framework is separated from the instance to support DKIM. 4.2 New RR Definitions Should Support Infrastructure, not DKIM A previously noted a policy infrastructure should separate the specific needs of DKIM from needs that are general to multiple protocols. If it is the case that a new RR definition is essential and it is not possible to deploy DKIM in a manner that meets all the objectives of DKIM within the capabilities of the legacy DNS then whatever RRs are defined should be designed to support a policy infrastructure rather than the specific DKIM protocol. It is simply not acceptable or sustainable for all attempts to define protocol policy records to be gated on a single IETF working group, particularly one that will in any case be wound up as soon as the DNS Security deployment is complete. There are many forums that define Internet protocols and every protocol will require policy. There are already far more unofficial definitions of DNS SRV entries than there are official ones. Unless a realistic approach is adopted that supports the principal of independent innovation once considered the founding principle of the IETF as an institution. Notices Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Hallam-Baker Expires August 2006 Page 8 Considerations for DKIM Policy Language June 2006 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Acknowledgments The author would like to acknowledge the contribution of Stephen Farrell without whose insistence on writing it this document would never have been written. Authors’ Addresses Phillip Hallam-Baker VeriSign Inc. pbaker@verisign.com Hallam-Baker Expires August 2006 Page 9