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

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.

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

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

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

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

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

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

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


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

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

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

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

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

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


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