ietf-mailsig
[Top] [All Lists]

Re: [ietf-dkim] Purpose and sequence for DKIM specification anddeployment

2005-08-29 11:43:25

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 are acceptable.

--
Arvel


----- Original Message ----- From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, August 27, 2005 2:18 AM
Subject: [ietf-dkim] Purpose and sequence for DKIM specification anddeployment


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





<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ietf-dkim] Purpose and sequence for DKIM specification anddeployment, Arvel Hathcock <=