Folks,
This is a personal attempt at describing a two-stage sequence of producing DKIM
capabilities, to permit the earliest possible deployment of a basic service,
followed by SSP (Sender Signing Policy) as a first increment. It highlights
incremental benefits and suggests incremental
implementation, to show that the pieces need not be developed or deployed at the
same time. The sequence matches what is already specified in the DKIM draft
charter <http://mipassoc.org/dkim/dkim-charter-05dc.txt> and what follows, here,
does not suggest changing the charter. Rather, it emphasizes the benefit of the
staged effort that is specified.
Considering these stages separately also has the
considerable benefit of highlighting two different
goals for DKIM.
Internet specifications have a long history of incremental development and
deployment. Still, there is always an important question of what to develop and
deploy, as a first step. For example there is the possibility that deploying
something too early can hinder later enhancement efforts: The architecture might
not be sufficiently mature to permit a desired enhancement, or the market might
not be sufficiently motivated to adopt that later enhancement.
An IETF working group charter might reflect multiple releases, in a sequence, or
it might specify only the single, next target. The basic rule for an individual
specification release is that it provide a useful capability.
BACKGROUND
Purpose of DKIM:
Quoting a recent posting by Eric Allman: "DKIM is a protocol enabling
some entity to assert accountability for the message. 'Accountability' doesn't
necessarily have to be attached to authorship of the message, the content of
the message, or any header fields of the message, because the primary point is
simply to create an authenticated identity of an accountable entity to which a
reputation can be attached."
DKIM identifies the entity by a domain name. It uses classic
cryptographic techniques to verifiably associate that domain name with a
particular message. It is, therefore, easy to view DKIM as having these
techniques and the resulting "signature" as its focus. However, they are merely
a means of achieving an end.
The end being sought is to ensure that a verifiable identity
can be associated with a message and later used by an
intermediary or a recipient.
Except when discussing the details of the cryptographic techniques, it is
therefore better to refer to a "DKIM identity", rather than a "DKIM signature".
Security Role:
DKIM's basic mechanism performs simple message signing for any identity
wishing to be held accountable for the message. The security function performed
by the signing is authentication of that asserted identity.
The SSP mechanism provides the security function of authorization, to
determine whether the sending of unsigned messages is authorized or prohibited.
Divide and Conquer:
The reason for pursuing a sequential factoring of both the specification
and the deployment work for DKIM is to get (substantial) benefit from the work
and to be able to feed early experience back into the standards process. This
permits later features to be much more pragmatic.
In terms of standards process management, the more features that must be
discussed, the longer things take, especially for a group as diverse as the DKIM
mailing list. Hence, a major process benefit in this sort of factoring is
greatly improved group focus.
Maturity:
In addition, the core signing and verifying document is far more mature
than the SSP specification and our experience with the functions it performs is
far greater. This is underscored by already having interoperable
implementations of it. Therefore we should be able to complete standardization
of it much sooner than either of the SSP features.
In terms of deployment and operation, the base specification is likely to
be simpler than the SSP functions. For the base signing function, the only
"coordinating" aspect between signer and verifier is the key record in the DNS.
The nature of the information in this record is very straightforward and
therefore not likely to have unexpected effects, in terms of semantics or
operations.
In contrast, SSP is in an entirely different league of (im)maturity, both
in terms of the specification document and, more importantly, in terms of
community operational experience. This type of feature does not have any real
precedent for Internet-scale use, so we can not be quite sure that its
interoperability (semantics), administration and operation effects will be what
we intend (or can accept.)
Risks:
The development and administration work for SSP looks deceptively simple.
What we do not yet know is whether there are interaction effects for different
usage scenarios, such as mobile users or authorized third-party senders. SSP
has an impact when the service provider does not participate in the RFC2822.From
(originating domain) policy enforcement. Hence, like path registration, SSP
creates a dependency between two, potentially independent services. This can be
problematic. Note that related dependencies have created difficulty for path
registration schemes.
The other side of the concern about risks is whether deploying the base
document, prior to deploying the SSP features, will hurt development, deployment
or use of the SSP features. The discussion, below, shows how to incrementally
add the SSP features. This additional functionality does not alter the base
specification and actually relies on its details remarkably little. Hence there
is little danger that releasing the base capability first will create any
technical barriers to adoption of SSP. This is especially true given the
intense, current interest in SSP: those working on the base already have in mind
these additional features.
That leaves the question of market interest in incremental adoption. If the
DKIM base is deployed, will it create a disincentive for adoption of the SSP
features? The answer to this largely hinges on whether the incremental features
provide enough additional value. Certainly the sense of those working on DKIM is
that the features are likely to be enormously useful.
INCREMENTAL DKIM FEATURE DEVELOPMENT
(1) DKIM FEATURE:
Any verified identity
A. BENEFIT:
Provides an accountable identity, which permits application of assessments
based on a domain name (eg, rather than on an IP Address.)
Likely primary
use will be for whitelisted domains. Initial whitelists can be private, and
therefore quickly developed.
B. SIGNER EFFORT:
i. Add Key to a DNS record associated with the accountable domain
ii. Add signing code to a module within the Administrative Environment
of the signing entity.
C. VERIFIER EFFORT:
i. Add verifying code to module within Administrative Environment.
Treat verification failure the same as if no signature were present.
ii. Develop private whitelist or acquire access to third-party,
domain-based whitelist(s). The benefit of a private list is that it requires no
standardization effort to support it. On the other hand, it often does not
scale well: such private lists require extensive, on-going maintenance and
usually are incomplete and have inaccurate entries; in addition they do not
list first-time contacts.
iii. Add assessment mechanism(s), as appropriate
D. RISKS:
i. Security of the DNS
ii. Effort to administer key records and keep them up to date
iii. Changes in DNS traffic affecting servers and possibly altering
client caching behaviors.
iv. Message transit through intermediate MTAs might alter content or
encoding in ways that break the signature algorithm.
v. Reliance on the mere fact of signing, to indicate acceptability of
a message.
vi. Performance impacts on infrastructure. Signing and verifying are
not cheap operations, and may open the door to some service denial attacks.
(2) DKIM FEATURE:
Determine whether origination domain permits unsigned messages.
A. BENEFIT:
i. Verifier can cooperate to enforce requirement of the purported
origination to sign all messages
ii. Additional method of identifying unauthorized use of an origination
domain
B. SIGNER EFFORT:
Under a domain name, create an SSP DNS record for domain-wide
requirement to sign all messages
C. VERIFIER EFFORT:
Add module that checks for unsigned messages and uses origination domain
name to query for DNS record. If the origination requires signing then treat
message as a forgery.
D. RISKS:
i. Mistaking domain-wide requirement as implying that domain sends
acceptable mail.
ii. Ability to ensure all valid mail from domain is signed.
iii. Presence of SSP might cause recipients to fail to consider other
types of name falsification other, such through "similar" domain names, eg,
example.com vs examp1e.com.
iv. Impact of message modification, intentional or not, that break
signatures and, presumably, thereby reduce delivery reliability.
v. Potential problems for mobility and third-party services (such as
mailing list signing) when third-party does not participate in SSP for
rfc2822.From domain.
--
d/
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
ietf-dkim mailing list
http://dkim.org