Internet DRAFT - draft-hallambaker-pcon
draft-hallambaker-pcon
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
