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

[Jim Fenton]

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