Douglas Otis wrote:
Today I'll publish a rough-cut draft for the recognition options that
have been suggested. Here is a quick review of your threat summary.
1.1. Terminology and Model
It would be better to put a place holder for the signer-practices
query as well. An alternative to an authorization strategy would be
effective against many modes of attack. Once a recognition strategy
is considered, this signer-practices mechanism changes substantially.
Do you mean that there should be some informative description of the
signer practices query here (as with the other placeholder)?
This talks about falsifying the "origin address" of messages. Should
the base DKIM draft be seen as a means to ensure the identity of the
author, which I assume this "origin address" is intended to imply?
Any suggestion that a particular header _may_ have the email-address
restricted by DKIM invites open-ended authorization mechanisms that
have in the past been used to unfairly shift the burden of
accountability, and may lead to highly dangerous assurances.
"Origin address" is defined in Appendix A (in fact, it's the only thing
defined in Appendix A at this point!). Unlike S/MIME and PGP
signatures, DKIM signatures do not assert the identity of the author, so
the origin address does not imply that. You're still missing me with
terms like "open-ended authorization mechanisms"; since you say they
have been unfairly used in the past, can you give an example?
2.3.1. Externally-located Bad Actors
As the majority of abusive email is being sent through compromised
systems, why should DKIM ignore what can be done to identify these
sources within the sending Administrative Unit? That should be a
DKIM could be used within the sending Administrative Unit (AU), but to
fully do so would imply signing at the MUA. Within the sending AU,
there are easier-to-use mechanisms available to achieve the same thing:
for the originator to authenticate themselves to the first-hop MTA, for
example. DKIM signatures come from the domain owner; this is most
easily (and most securely) administered if signing is done relatively
2.3.3. Within Recipient's Administrative Unit
Rather than recommending [I-D.kucherawy-sender-auth-header] headers,
the MDA could sign and avoid many receiving Administrative-Unit attacks.
It could, but deployment would suffer because the MUA would need to
change in order to verify that signature. DKIM can be deployed in that
manner, with no change to the specifications, if spoofed
Authorization-results headers get to be a problem. Perhaps this should
be pointed out in the threat document.
3.1. Use of Arbitrary Identities
"It also does not guarantee the accountability of the signer, since
that is limited by the extent to which domain registration requires
accountability for its registrants."
This is a poor use of the word accountability. Accountability
implies being held to an expectation. The signer is always
accountable for their actions, however their actions may not always
A valid signature can be used to properly assign accountability,
however a valid signature does not imply that the signer can be trusted.
I'll stipulate that accountability may be the wrong word. However, your
rewording doesn't pick up the concept that the domain registration may
be fraudulent, and in that case I don't think it's properly assigning
accountability. I was trying to convey that there is a dependency here
that puts an upper bound (a rather low upper bound, at that) on the
ability to identify the domain owner of a properly signed message.
3.2. Use of Specific Identities
This could be further illustrated by "online-example.com" where
people do not understand the significance of "-" from that of the
".". Continue by also reviewing unicode extensions related to
RFC2047 and RFC3492, (the Unicode TR 36 reference in the
international domain names section seems to imply this does not
affect non-internationalized domains). Add further examples where
the domain name is in Puny-Code. Considering that in most cases the
native character-repertoire would be different from that of the raw
Puny-Code, visual examination of the domain name becomes virtually
meaningless. Unless DKIM avoids reliance upon visual examination,
little is gained. Any DKIM assurances that a signature was verified
and was in compliance with some practice will only increases the
success of targeted attacks.
Thanks for the suggestions, although I thought that the "examp1e.com"
example made it clear that this isn't strictly an IDN problem. Since
I'm not familiar with all of these, can you write some text for this?
3.2.1. Exploitation of Social Relationships
"DKIM would be effective in mitigating these acts by limiting the
scope of origin addresses for which a valid signature can be obtained
when sending the messages from other locations."
What mechanism is this describing? After completing section 3.2,
3.2.1 can not make a statement of effectiveness, nor is this a direct
function of DKIM.
The concept is that if one of my correspondents with my address in their
address book gets compromised by malware, it currently is likely to
start sending messages from their system using "fenton(_at_)cisco(_dot_)com" as
From address. DKIM is effective in that it is not possible for them to
send such a message with a DKIM signature from the cisco.com domain
owner. If they want to send messages signed by the address of origin,
their choice of addresses is much more limited.
3.2.2. Identity-Related Fraud
This does not make any clear statement other than to say that the
"address of origin" may contribute to fraud. How does this relate to
Agreed, this section needs to say something about DKIM effectiveness in
this case, like the other 3.x sections do.
3.2.3. Reputation Attacks
DKIM will not defeat a DSN with an invalid return-path, as the
content of the message would be expected to have been changed. One
practice similar to or part of the "joe-job" (Spam appearing to be
from an innocent third party, and named after a victim Joes.com) is
to invoke a bounce where the return-path is also invalid and used to
eventually deliver the message. This would work much like not
putting a stamp on a letter where the return-address contains the
desired recipient. Unless DKIM signatures are checked within the
SMTP session, an invalid signature may generate the "desired"
bounce. As reputation should be based upon verifiable source
identifiers within the message, reputation would not be effective at
dealing with invalid addresses when not used by the recipient
creating the DSN. Reputation does not deal with message replay abuse
I would probably characterize this as a different sort of attack, a
"reflection attack", and put it in its own section. Sound OK?
4.1. Attacks Against Message Signatures
Why would a Signed message replay have a low impact when the
likelihood is high? What identity is being used to accrue
reputations? The same issue would be involved with compromised
systems within the originators Administrative Unit. The Display name
abuse is only indicated as having a Medium impact, but for the
majority of recipients, this would represent a significant risk,
especially if there was any assurances made.
The definitions of impact and likelihood are given at the beginning of
section 4. For signed message replay, impact is low because the replay
affects only that message; it does not, for example affect other
messages from the domain.
DKIM does not define a reputation service, so the "what identity"
question is moot.
I tagged the impact of display name abuse as medium because it impacts
some MUAs more than others; those that hide the email address and only
show the display name are more problematic.
4.1.9. Body Length Limit Abuse
"Recipients need to use means to, at a minimum, identify the unsigned
content in the message."
What is this assuming?
The problem here might be the assumption that the verifier (typically an
MTA) knows what the MUA is and whether it can distinctively display the
signed content distinguished from the unsigned content. Another
approach is just to truncate the message at the signed content length
when it is verified.
Consider dropping the following sections for now:
4.2.3. Denial-of-Service Attack Against Signing Policy
4.2.4. Use of Multiple From Addresses
5. Derived Requirements
This section is incomplete, but was added in response to a specific
request. It makes sense to me because we're doing this before the WG
takes up the base and SSP drafts. To some extent we get to define
what's in the threat analysis document, so if there is consensus (and
agreement from the chairs) that we don't need this section, I'll make it
ietf-dkim mailing list