[ietf-dkim] Purpose and sequence for DKIM specification
dotis at mail-abuse.org
Sun Aug 28 18:10:54 PDT 2005
On Sun, 2005-08-28 at 12:47 -0700, Dave Crocker wrote:
> >> 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.
> > Your list does not offer the possibility of establishing
> > opportunistic identity schemes that could based upon the selective
> > binding of signed message identifiers retained locally.
> 1. I am pretty sure that I have no idea what you are describing.
This has been discussed on the list. I will attempt to describe this in
an update of the mass-rep draft.
> 2. The description I wrote is intended to cover the existing DKIM
> specification and its intent. As nearly as I can tell, you are
> suggesting some sort of functionality that is both theoretical --
> hence needing to establish community need and interest -- and outside
> the scope of the current effort (so far).
Previously closed efforts developed the SSP draft. The intent of SSP is
not very clear from a chartering perspective. The intent is made less
clear by employing the term forgery. With respect to offering
protection from those attempting to forge the author of a prior
correspondence, opportunistic identification offers _better_ protections
than that achieved using domain-wide authorization schemes.
Domain authorization mechanisms should not make anti-forgery claims,
despite the misleading charter goal. A domain is never the author of a
message. Nor would a message being from an authorized domain assure the
recipient that forgery has been prevented. Secondly, the circuitous
matrix of information involved in such a mailbox-domain authorization
approach would be difficult to convey to the recipient as the basis for
acceptance. Opportunistic identifications can be limited to direct and
immediate information found within the message itself.
> >> The SSP mechanism provides the security function of authorization,
> >> to determine whether the sending of unsigned messages is authorized
> >> or prohibited.
> > This can work in conjunction with a host name as was done with the
> > HELO.
> It can work in conjunction with lots of things. Are you suggesting
> changes to the text I wrote? To the specifications? To the charter?
The text within the charter does not describe how the domain is
determined. In the case where the assertion is based upon a host name,
this would provide direct authorizations which can be immediately
applied to the server, irrespective of any message header. Immediate
and direct authorizations could be beneficial as part of a low-level
In the case where the domain is obtained from a purported originating
mailbox-domain, authorizations are indirect and may be unexpectedly
disruptive or risky when inconsistently applied. Indirect
authorizations represent a significant increase in the level of
complexity in terms of support and administration.
> > There would be an inordinately high overhead associated with attempts to
> > associate mail-box domain authorizations within third-party signed
> > messages.
> What is the "inordinately high overhead" you are referring to?
Walking up label-trees of all third-party mailbox-domains, where this
authorization may also be conveyed to a dereferenced domain, represents
a significant increase in the level of overhead and complexity. This
check would happen after the data phase, involve more comparisons, and
broadly encompass all domains. Domains that have not made any
indication of having published any such record or even that send mail.
This would involve the set of all mailbox-domains, versus the set of
signing domains. Initially, limiting lookups to the set of signing-
domains when adoption is low means there would be considerably less
More information about the ietf-dkim