[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ietf-dkim] Purpose and sequence for DKIM specification anddeployment
- To: "ietf-mailsig" <ietf-mailsig@xxxxxxx>
- Subject: Re: [ietf-dkim] Purpose and sequence for DKIM specification anddeployment
- From: "Arvel Hathcock" <arvel@xxxxxxxx>
- Date: Mon, 29 Aug 2005 13:27:32 -0500
- Dkim-signature: a=rsa-sha1; c=nowsp; d=altn.com; s=c3po; l=8529; t=1125340468; x=1125945268; email@example.com; q=dns; h=DomainKey-Signature: Received:Message-ID:From:To:References:Subject:Date:Organization: MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; b=gNCgXqvlm/dUzt7SD7Y+vDLcaMjDvHn1qSoIi+HbI+9SS/7WIVzPTU/ZJAQmDQaY Q3DcZWnrvLZyDi/PoUKSDHHBnT6r0eoyOcLvaBIot8xZQBVKdQDdodgmI24D8uMl BWPPpet3DljdEfbJDJbzRf3B0OcFhntweJ5+r/0rVDY=
- Domainkey-signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=from:message-id; b=H0mKVeeh+wMsVtSWZ6aYcNDWaZrIMM92QiC8MszBuurJ6waaC0d8ZEEJeVtMI+B/efLfJsuJ5yDpe7di/xUXdVmvHUA87aiwzbKDuyqz9w2hD96Y0kBenvKXZcH1oiiQTW+zX6ZClKbDTnisRD3axi8h2GLjSg1W6cQibYJqaIo=;
- List-archive: <http://www.imc.org/ietf-mailsig/mail-archive/>
- List-id: <ietf-mailsig.imc.org>
- List-unsubscribe: <mailto:firstname.lastname@example.org?body=unsubscribe>
- Organization: Alt-N Technologies
- References: <431013C5.email@example.com>
- Reply-to: arvel@xxxxxxxx
- Sender: owner-ietf-mailsig@xxxxxxxxxxxx
This is a very well thought out plan.
I note though that it sites as features (a) the authentication of a DKIM
identity and (b) the use of SSP to handle unsigned mail. There is also the
issue of (c) the use of SSP to determine the types of DKIM identities that
----- Original Message -----
From: "Dave Crocker" <dhc@xxxxxxxxxxxx>
Sent: Saturday, August 27, 2005 2:18 AM
Subject: [ietf-dkim] Purpose and sequence for DKIM specification
This is a personal attempt at describing a two-stage sequence of producing
capabilities, to permit the earliest possible deployment of a basic
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
same time. The sequence matches what is already specified in the DKIM
charter <http://mipassoc.org/dkim/dkim-charter-05dc.txt> and what follows,
does not suggest changing the charter. Rather, it emphasizes the benefit
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
deploy, as a first step. For example there is the possibility that
something too early can hinder later enhancement efforts: The architecture
not be sufficiently mature to permit a desired enhancement, or the market
not be sufficiently motivated to adopt that later enhancement.
An IETF working group charter might reflect multiple releases, in a
it might specify only the single, next target. The basic rule for an
specification release is that it provide a useful capability.
Purpose of DKIM:
Quoting a recent posting by Eric Allman: "DKIM is a protocol enabling
some entity to assert accountability for the message. 'Accountability'
necessarily have to be attached to authorship of the message, the content
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
DKIM's basic mechanism performs simple message signing for any
wishing to be held accountable for the message. The security function
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
Divide and Conquer:
The reason for pursuing a sequential factoring of both the
and the deployment work for DKIM is to get (substantial) benefit from the
and to be able to feed early experience back into the standards process.
permits later features to be much more pragmatic.
In terms of standards process management, the more features that must
discussed, the longer things take, especially for a group as diverse as
mailing list. Hence, a major process benefit in this sort of factoring is
greatly improved group focus.
In addition, the core signing and verifying document is far more
than the SSP specification and our experience with the functions it
far greater. This is underscored by already having interoperable
implementations of it. Therefore we should be able to complete
of it much sooner than either of the SSP features.
In terms of deployment and operation, the base specification is
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
The nature of the information in this record is very straightforward and
therefore not likely to have unexpected effects, in terms of semantics or
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.)
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
The other side of the concern about risks is whether deploying the
document, prior to deploying the SSP features, will hurt development,
or use of the SSP features. The discussion, below, shows how to
add the SSP features. This additional functionality does not alter the
specification and actually relies on its details remarkably little. Hence
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
these additional features.
That leaves the question of market interest in incremental adoption.
DKIM base is deployed, will it create a disincentive for adoption of the
features? The answer to this largely hinges on whether the incremental
provide enough additional value. Certainly the sense of those working on
that the features are likely to be enormously useful.
INCREMENTAL DKIM FEATURE DEVELOPMENT
(1) DKIM FEATURE:
Any verified identity
Provides an accountable identity, which permits application of
based on a domain name (eg, rather than on an IP Address.)
use will be for whitelisted domains. Initial whitelists can be private,
therefore quickly developed.
B. SIGNER EFFORT:
i. Add Key to a DNS record associated with the accountable
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
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
standardization effort to support it. On the other hand, it often does
scale well: such private lists require extensive, on-going maintenance and
usually are incomplete and have inaccurate entries; in addition they do
list first-time contacts.
iii. Add assessment mechanism(s), as appropriate
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
client caching behaviors.
iv. Message transit through intermediate MTAs might alter content
encoding in ways that break the signature algorithm.
v. Reliance on the mere fact of signing, to indicate
vi. Performance impacts on infrastructure. Signing and verifying
not cheap operations, and may open the door to some service denial
(2) DKIM FEATURE:
Determine whether origination domain permits unsigned messages.
i. Verifier can cooperate to enforce requirement of the
origination to sign all messages
ii. Additional method of identifying unauthorized use of an
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
name to query for DNS record. If the origination requires signing then
message as a forgery.
i. Mistaking domain-wide requirement as implying that domain
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
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.
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
ietf-dkim mailing list