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