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

[Jim Fenton]

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