ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

2006-01-05 23:27:09
Douglas Otis wrote:

Jim,

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)?




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?




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.




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




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





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.




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?




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

Why?

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
go away.

-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org