Douglas Otis wrote:
On Jan 5, 2006, at 10:08 PM, Jim Fenton wrote:
Douglas Otis wrote:
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)?
DKIM could offer greater protection by making it practical for the
protection to be generally applied. An authorization scheme as
envisioned in SSP limits applicability of DKIM's protection to
domains willing to relinquish many services, such as mailing-lists or
alternative providers.
As such, and with a general understanding signer-practices are still
in transition, excluding conclusions or assurance related to this
mechanism could be postponed until further progress in made in that
area. Much better protection generally applied is possible. The
focus should be on the base DKIM draft for the threat review.
I was hoping for a "yes" or "no". Your initial comment sounded like it
was asking for a description of SSP to be included, and your last
paragraph sounds the opposite.
2.1. Characteristics
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?
"Origin address - The address on an email message, typically the RFC
2822 From: address, which is associated with the alleged author of
the message and is displayed by the recipient's MUA as the source of
the message."
This appendix definition is not a valid statement. The author of a
message is _not_ the source of the message. The DKIM signature
provides an indication of the source of a message. It would be an
assumption that some email-address was valid, even when within the
same domain as the signature, unless there was some explicit
assurance made by the signer with respect to this conclusion.
Authorization may be seen as a method to communicate such assurances,
but there are better ways that can be more generally applied and
offer different gradations of assurances as well.
Help me clarify the definition then. When a typical user looks at a
message, they decide "who it's from", as in "Oh, this is from Doug." I
believe that with most MUAs this is the From address (or the display
name in the From address). I have covered display name abuse in a
separate section. There is no assertion of authorship from DKIM,
although I used the term "alleged author" to try to convey the "who it's
from" concept. The address corresponding to "who it's from" is what I
want to call the Origin Address.
By "open-ended authorization" this means third-party signatures or no
signatures are permitted. Accruing reputation based upon discovery
of an authorization, as with Sender-ID which described this as
"authentication," would be an example of the unfair use of
authorization. The desire to shift accountability onto the email-
address domain owner has caused a fair amount of equivocation with
respect to what is authentication. As a result, it would be rather
foolish to assume that open-ended authorizations are innocuous.
Without SSP, third-party signatures and no signatures are also
permitted. That's about as open-ended as it gets. SSP closes that
loophole for certain domains that behave in particular ways. That's
about as specific as I'd like to get until we get into the SSP
discussion in a few months.
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
primary focus.
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 centrally.
As an option, it should be possible to establish a convention noting
the account used to access the MSA or which delegated key was used.
If you review the DKIM-Options draft, this describes how this
information may be carried in both centralized and non-centralized
settings. Again, as compromised systems within the originating AU
represent where a substantial amount of spam originates, being able
to track it systematically by third-parties should permit rapid
curtailment.
I couldn't find this in the DKIM-Options draft. One way to look at this
might be to use the local part of the i= tag to indicate the account
accessing the MSA, although this might have problems if an
administrative assistant needs to send mail someone he or she supports.
In that case if we used i=, it might cause the signature to be a
third-party sig. It might also have privacy problems; that VP (let's
say) might not want it known that the message was sent by their
administrative assistant.
I'm thinking that it's up to the signing domain to include whatever
information (if any) they believe will help them track the source of
abuse. It might be the submitter's username, or it might be an opaque
version that only the domain owner can associate with a real username,
for much the same reason as the opaque identifiers you have been
advocating are opaque.
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.
The MUA should only see the MDA signature. The MDA signature would
specifically be declared as invalid in other domains to prevent this
as a source for a replay attack. If you review the DKIM-Options
draft, this is clarified there.
This would require abandoning the concept that DKIM will be usable by
many legacy MUAs, since they will need to verify a signature. I would
like to see substantial consensus that the additional security of
running signatures all the way to the MUA is worth it before we change
this. Remember that the verifier can be the last MTA/MDA in the chain;
the opportunities for spoofing a verification header are fairly small at
that point.
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
be trustworthy.
reworded:
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.
Your concerns seem to be based upon assumptions related to assuring
the identity of individuals. This is well beyond what is expected of
DKIM. S/MIME or OpenPGP attempt to offer assurance of the
individual. It would seem greater clarity would be achieved by
stating only the _domain_ is being held accountable without this
implying there is any DKIM association whatsoever with individuals.
The trustworthiness of the domain as an identifier and how it may
relate to some individual (good or bad) would require subsequent
evaluation independent of DKIM.
As you and several others have pointed out, it's not the role of DKIM to
identify the individual that is responsible for the domain, and
therefore responsible for signing. It's really more like "this message
was signed by the owner of domain [foo], whoever that is." I'll try to
rework that section to remove that implication.
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?
Sure. : )
Thanks for your text; I'll send a separate response to that message.
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 the 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.
Again that is assuming the use of a restrictive authorization mode
(which would preclude your participation on this list, for example).
This also assumes how SSP works. Could this be postponed until SSP
is better developed?
My wording doesn't depend on SSP; note the text, "limiting the scope of
origin addresses for which a valid signature can be obtained". This is
true with or without SSP.
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 DKIM?
Agreed, this section needs to say something about DKIM effectiveness
in this case, like the other 3.x sections do.
Focus upon only holding the signing-domain accountable. There are
many threats that need to be handled in this respect. Any statements
regarding the protection of email-addresses would be based upon
conjecture at this point. DKIM in and of itself offers significant
value by providing stable source identifiers. While a highly
constraining authorization scheme may attempt to utilize the base
DKIM signature, there are other mechanisms that can be more generally
applied to increase protections obtained by DKIM without curtailing
most of the freedoms users currently enjoy.
When you're talking about holding some domain accountable, you're
getting into the realm of defining how reputation systems operate. I,
too, think that a reputation system sould hold the signing-domain, and
not some other domain, accountable for messages it signs. But we're not
designing the reputation system here, so let's let it drop.
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 either.
I would probably characterize this as a different sort of attack, a
"reflection attack", and put it in its own section. Sound OK?
It would seem that a recommendation to check signatures prior to
message acceptance, as well as considering some form of return-path
tagging would be needed. Calling this a "reflection attack" seems okay.
Are you saying that you wouldn't accept messages without a valid
signature? Sounds like a dangerous thing to do except in some very
specific cases. Or that you would only generate bounce messages for
signed messages (and presumably ones signed by the RCPT-From domain)?
That seems dicey too.
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.
There are no limits for the number of times a message is replicated,
so saying "that message" does not provide any perspective of the
magnitude. The impact upon the domain's reputation would be high
when this attack causes the domain to be blocked. Such a message
replay attack could include multiple messages to make individual
signature blocking seem fruitless. Reputation on signatures would
represent a substantially large database that would require a longer
period of time to disseminate. There are techniques that could buy
precious time when the message may be a replay. There are also
strategies that could consolidate this data down to accounts, rather
than individual signatures. Even these accounts could include a
"redeemed" code prefix (a table that contains the current try at
being good, referenced by the account). How this could work is
explained in the DKIM-Option draft.
The degree to which a replay affects reputation depends on the way the
reputation system works. It could, for example, only penalize the
reputation once for each unique signature. I'm not saying this is the
right thing to do, just pointing out that this is reputation-system
dependent.
I'd be interested in opinions from others whether I mis-classified the
impact of replay attacks.
DKIM does not define a reputation service, so the "what identity"
question is moot.
The concern is whether there is a practical solution for this
problem. The identity being used to mitigate this problem will
significantly impact practicality.
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.
This category of MUAs represents the majority being used and are not
readily changed. Assuming that MUAs will change opens up a
significant number of far superior solutions. Either assume the MUA
do not change and the email-address is not seen, or consider what a
modification to the MUA could achieve. It should be fair to say that
until the MUAs change, DKIM does not greatly mitigate the impact of
spoofing. There have been many examples of mind's ability to ignore
misplaced characters and such. I would also suggest that even when
the email-address is displayed, the rich character-repertoire
available to the sender, as well as areas depending upon Puny-Code,
visual examination still leaves the recipient highly prone. This
exposure also requires legitimate senders to expend a fair amount of
resources to obtain look-alike domains, which often involves
litigation. This is where DKIM can make a significant difference
that would be greatly enhanced by providing information what elements
can be used to isolate the source of a message. This too has been
clarified in the DKIM-Options draft. Until then, the impact remains
high and the likelihood is high.
Outlook is the MUA I'm most familiar with that often doesn't display the
email address. I'm not an Outlook user myself, so I don't know what the
circumstances are that it displays the address and when it doesn't; I'll
try to chat with some of the Outlookers (?) around here about what can
be done.
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.
This is assuming MUAs change. Truncation should be the rule without
exceptions. The sender should obfuscate the prior signature and
resign the message with the correct message length. Signature
obfuscation reduces the number of sources for a replay attack,
especially as this would be commonly done by a list server.
An obfuscated signature is as good as no signature, so I gather you're
advocating that re-signers remove prior signatures. Removing the prior
signature in order to avoid feeding a replay attack (presumably a Signed
Message Replay) is an interesting thought although I wonder if there
aren't better sources of signed messages available.
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
Why?
As you and Stephen have indicated, this would be based upon
conjecture. It seems a separate draft that involves the concerns of
SSP would be appropriate rather than prematurely assuming the outcome
of the SSP effort.
As Stephen has said, absent substantial consensus that we should
separate SSP from the threats document, we will continue to include it,
in as general terms as possible.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org