[ietf-dkim] Purpose and sequence for DKIM
specification and deployment
dotis at mail-abuse.org
Mon Aug 29 02:47:03 PDT 2005
On Sun, 2005-08-28 at 18:44 -0700, Dave Crocker wrote:
> 1. Since I've been reading the list rather closely, there is some chance that I
> am not the only one who did not understand what you were talking about.
I will attempt to provide a more coherent presentation of the concept in
the draft revision as I suggested.
> 2. If the issue has to do with reputation, it is out of scope for DKIM.
This has to do with being able to recognize a prior correspondent
without the use of complex and problematic authorizations. This would
work in conjunction with a scheme that detects when a message was not
sent directly to the recipient. There would also be a field that adds a
type of account-cookie or domain-cookie that provides a basis for
These features include replay abuse abatement, but also provides a basis
that could be used in conjunction with opportunistic identifications
where the MUA would bind this cookie with the signing-domain and keyed
off of the mailbox-domain, mailbox-address or the pretty-name. The
signing header could indicate the amount of the binding needed to
isolate or resolve to domain assured originator identifiers.
> 3. What changes you are suggesting, if any, for any of the DKIM documents,
> existing or needed?
Inclusion of the revocation-identifier as described. Adding binding
recommendations would reduce user interaction required to support the
scheme. In some cases, the bindings could be automated.
> "Opportunistic identification" sounds fascinating.
> a) where is is defined? and
Consider the strategy used with SSH for self signed certificates. DKIM
could be considered a type of self-signed certificate.
The elemental basis of this identification has been defined in:
The title of this draft is not about implementing a reputation mechanism
or communicating with a reputation service. This draft's title refers
to concerns regarding protection of the sending-domain's reputation
through controls that must be available to abate abuse. Abuse is a real
threat. I would hope abating replay abuse for example is not seen out
of scope. The ability to bind opaque signed identifiers to prevent
targeted spoofing would be another feature offered.
> b) it sounds like a different scheme than DKIM is using, so I am not
> clear how it is relevant to the DKIM discussion.
This question seems rather circular for a discussion of general goals
attempting to define a minimal set of essential elements to defend
against expected threats. Although SSP was offered as a solution, does
that exclude other equivalent or superior methods?
What is the goal that SSP achieves?
How does SSP resolve:
- DoS issues?
- replay abuse?
- inter-domain spoofing issues?
- third-party signing issues?
- increased overheads?
> > Domain authorization mechanisms should not make anti-forgery claims,
> > despite the misleading charter goal. A domain is never the author of a
> > message.
> Any claims at prevention or detection of misbehavior certainly need to be
> clearly explained. However I do not believe there is any DKIM documentation
> that claims that a domain is the author of a message.
I disagree. It would be like saying DKIM prevents forgery (provided the
first name is correct and was not endorsed by a third-party). DKIM may
allow the association of mailbox-domains with a verified signature.
This does not prevent mailbox-address forgery nor would DKIM
authenticate the mailbox-address.
> I believe the claim regarding the DKIM bases's utility against forgery is that
> an author attempting to assert an rfc2822.From address that has a domain name
> for which the author is not authorized will not be able to generate a valid DKIM
A claim regarding a statement about forgery immediately followed by a
statement that DKIM authenticates headers is misleading to say the
least. With DKIM, anyone could provide a falsified RFC2822.From address
and provide a valid DKIM signature.
> If the domain SSP requires signatures on all messages and an unauthorized author
> asserts the From address for the domain but does not sign the message, then the
> validating agent will treat the message as an error.
A valid signature may not be related to the RFC2822.From domain.
> Both of these serve to close (or at least narrow) the hole that permits forgery
> of rfc2822.From addresses.
These two requirements do not represent forgery protection where even
describing this as narrowing the hole permitting forgery is misleading.
DKIM does not authenticate the RFC2822.From header. Only the signature
Attempts may be made to bind this signature to some mailbox-domain.
Preventing third-party signatures will disrupt email delivery in many
cases. Selectively preventing third-party signatures will carry a high
overhead. Even when third-party signatures are excluded:
- inter-domain falsification of the RFC2822.From remains possible
- an unseen Sender-header may have been applied
- only the pretty names may be visible
> > 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.
> So it is probably good that the DKIM working group effort is not targeting user
> interface issues needed to communicate identity validation to the user.
Why is the term forgery in the charter? The concept of forgery is
related to falsifying the identity of the author as understood by the
recipient. SSP is about authorizing a possibly unseen _mailbox-domain_
only when specific domain-wide assertions are applied and then checked.
Even when SSP is applied to a visual mailbox-domain, the recipient will
not know the number of possible domains still able to forge this
identity. Without per-user keys, it would be impossible to make
assurances related to the author, which should be out of scope for DKIM.
So should the concept of forgery, as DKIM does not assure or
authenticate the purported originator mailbox-address. Such assurances
are clearly suited for S/MIME or OpenPGP.
> > The text within the charter does not describe how the domain is
> > determined.
> "Determined"? Do you mean chosen by the signer or found by the verifier? The
> former is outside the scope of our work, relying on something like "whatever the
> signer believes they should use", and the latter is from the signature field.
> So what do you mean?
Perhaps I need to understand how you view the goals of the charter.
What is meant by the authentication of headers as related to forgery?
> "Host name"? DKIM uses the term "domain name" and does not constrain it to a
> host name.
> "Applied to the server"? What does this mean and how is it relevant to DKIM?
This would depend upon how the recipient defends resources and would be
related to permissions derived from the accountable domain established
> > 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.
> Disruptive in what way? Risky in what way?
This would be with respect to the handling and support of third-party
> How are you suggesting that the DKIM threat analysis, charter or specifications
> be changed?
I have been suggesting a different approach instead of SSP. A logical
breakdown of a threat analysis would be easier had the charter been
clearer about the goals. The current charter seems to miss the mark.
You have not commented upon the suggested changes to the charter. Is
this because you feel there is no benefit derived from establishing an
> >>> 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.
> 1. Neither DKIM base nor shavingsp refer to tree-walking.
Review section 5 of the SSP draft.
> 2. What does "conveyed to a dereferenced domain" mean?
The details have not been provided by Eric yet. He would like to add a
list of permitted domains.
> How does any of your concern apply to DKIM base or SSP?
This question seems to avoid the discussion of general goals. Part of a
process attempting to define a minimal set of essential elements to
defend against expected threats. When the conversation is specifically
related to dealing with threats, it would seem you want to not consider
alternatives because that is not related to DKIM or SSP. Do you see how
that is circular?
More information about the ietf-dkim