Subject: [ietf-dkim] draft-ietf-dkim-threats-00 Unreasonable estimate of impact from a highly probable exploit

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jan 2006 13:51:21 -0800

---[C: Unreasonable estimate of impact from a highly probable exploit.]
,---
| 4.1.  Attacks Against Message Signatures
|  ...
| Signed message replay                       |   Low  |    High    |
'---

This should read:

: Signed message replay                  |  Very High  |    High    |

How was this problem rated?  Any large domain has a continuous  
background of abuse being sent.  In some cases, this abuse may  
represent tens of thousands of compromised systems.  Any list-server  
is also prone, as there is no practical means to screen participants  
or expect effective outbound filters when the number of messages do  
not reflect the overall traffic until used in the replay.  Out of the  
millions of valid users within these domains, rate limiting has  
ensured these abusive systems represent a smaller percentage of the  
overall outbound email in most cases.  When used in conjunction with  
a replay strategy, rate limits will not remain effective, and yet the  
signature still remains valid.

Once the DKIM signature has any acceptance value, expect this problem  
to become paramount.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2006 22:44:24 +0000

Douglas Otis wrote:
> How was this problem rated?  

I guess Jim just used his judgment in the expectation that the WG
will review and come to consensus - which is quite the proper thing
to be doing IMO.

Also - there's no "Very High", most risk analysis approaches (that
don't try to sell you over-exactness) just use high/medium/low. So
we can interpret you as asking for "High" in the impact column for
4.1.5.

 > Any large domain has a continuous
> background of abuse being sent.  In some cases, this abuse may represent 
> tens of thousands of compromised systems.  Any list-server is also 
> prone, as there is no practical means to screen participants or expect 
> effective outbound filters when the number of messages do not reflect 
> the overall traffic until used in the replay.  Out of the millions of 
> valid users within these domains, rate limiting has ensured these 
> abusive systems represent a smaller percentage of the overall outbound 
> email in most cases.  When used in conjunction with a replay strategy, 
> rate limits will not remain effective, and yet the signature still 
> remains valid.
> 
> Once the DKIM signature has any acceptance value, expect this problem to 
> become paramount.

That doesn't make too much sense to me I'm afraid. (But since things
seem to work quicker/better when we do this: let's do it again:-)
Exactly what change are you proposing, other than s/Low/High/ above?

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jan 2006 15:19:27 -0800

> we can interpret you as asking for "High" in the impact column for  

The Very High was used to make a point.  Just High would be fine.

>> Any large domain has a continuous background of abuse being sent.   
>> In some cases, this abuse may represent tens of thousands of  
>> compromised systems.  Any list-server is also prone, as there is  
>> no practical means to screen participants or expect effective  
>> outbound filters when the number of messages do not reflect the  
>> overall traffic until used in the replay.  Out of the millions of  
>> abusive systems represent a smaller percentage of the overall  
>> outbound email in most cases.  When used in conjunction with a  
>> replay strategy, rate limits will not remain effective, and yet  
>> the signature still remains valid.
>> Once the DKIM signature has any acceptance value, expect this  
>> problem to become paramount.
>

Perhaps the following text could help justify this rating:

: Acceptance based upon the DKIM signature is in jeopardy of
: being exploited for any large domain, a domain offering
: public services, or where the network is exposed.  Abusive
: message replay will be able to circumvent containment
: strategies currently used to ensure only tolerable amounts
: of abuse are permitted.  Unless there are new strategies
: put in place to deal with this potential exploit, there is
: no reason to expect that DKIM will ever offer a means for
: basing acceptance, as this exploit will affect most domains.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 25 Jan 2006 15:44:25 +0100

> The Very High was used to make a point.  Just High would be

Your point is clear.  What you say is that MONs shouldn't sign
mails if they have no MoU with the (final) MRN to protect this
signature.  Otherwise the bad guys abuse this signature in a
replay attack against the reputation of the MON.

And you say that the _impact_ is HIGH.  In addition to a HIGH
likelihood.  That sounds fairly serious, I'd be interested to
hear some other opinions about this.  Your proposed workaround
is a bit too esoteric for my tastes, and IFF your analysis is
correct that could be a showstopper.  Is the "likelihood HIGH"
maybe a bit exaggerated ?                                    
                             Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2006 10:43:05 -0800

On Jan 25, 2006, at 6:44 AM, Frank Ellermann wrote:
>
> Is the "likelihood HIGH" maybe a bit exaggerated ?

This represents a bit of a conundrum.  The acceptance value of a  
signature can not be high with a message replay abuse problem.  The  
message replay abuse problem will be high when the signature's  
acceptance value is also high, but of course that would be  
impossible.  Likely, the signature may be used to excuse large  
domains leaking abuse and discovered on block-lists, but that will  
likely change when replay abuse becomes problematic.  Just as issues  
were raised about dealing with list-servers that do not implement  
DKIM, using a DKIM-Adopters-List when deciding whether to sign a  
message would tremendously reduce the number of broken signatures.   
If part of DKIM is to overlay the signature parameter with a result  
string at the edge of the AdmD, only domains controlled by bad actors  
would permit the possibility of there being any replay abuse.  Of  
course, this would also indicate bad actors have not fully adopted  
DKIM and should be removed from a DKIM-Adopters-List.

Another perhaps essential convention could demand that a DKIM- 
Adopters-List also indicates the EHLO can be verified.  This  
convention can prevent DoS effects created by bad actors adding DKIM  
signatures.  Such a list and practice would greatly increase the  
acceptance value of the DKIM signature and rule out bad actors with a  
history of abuse.  This would be rather straight forward to  
implement, and perhaps offering this as a service would help promote  
DKIM and ensure there are no problems later uncovered.  The list  
should be freely available.  To support the list, a fee could be  
charged to resolve abuse issues collected from a deposit for  
registering.  This would require a tracking and reporting scheme, but  
much of that already is in place.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Jan 2006 16:45:55 -0800

Here's my rationale for the values I put in the document regarding
Signed Message Replay.

There should perhaps be a third column in addition to "impact" and
"likelihood"; let's call it "utility".  The Signed Message Replay attack
in section 4.1.5 differs from nearly all of the other attacks in that
the attacker can't do everything they'd perhaps like.  If they steal the
private key for the domain, they can sign any message they like and send
out advertising or objectionable material, etc.  With the SMR attack
they can't do that -- they can only inappropriately distribute things
that are already signed.  This can be bad for the domain's reputation,
but if the attacker is looking to sell pharmecuticals, this isn't going
to help.

So I marked this attack as "low impact", in part because of its limited
utility, and in part because (in accordance with the definitions in
section 1.2) this attack deals with individual messages -- it doesn't
affect the majority of the messages from the domain, only those selected
by the attacker for replay.  Perhaps the definitions need adjusting but
I think we need some objective means for scoring the threats.

I do recognize my role on this is as a document editor, and I will
adjust the document to group consensus, but I wanted you to know where I
was coming from.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 26 Jan 2006 23:55:10 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>

> I do recognize my role on this is as a document editor, and
> I will adjust the document to group consensus, but I wanted you
> to know where I was coming from.

I hate going crazy on people's documents. :-) So I will minimize my
comments to illustrating how I view the Attacks and Ratings.

With my manager hat on, I read this document and ask myself a few
questions:

    "I trust the work. But what is the summary?"

    1) Which attacks do I need to be concern about?
    2) Which attacks are addressed by DKIM/SSP?

In the first question, I am interested in the "worst case" scenario.  To
do this, I can associate the ratings with a value, lets say:

    High     = 10
    M/H      = 8
    Medium   = 5
    Low      = 1

and get a rough rating for each attack by adding impact + likelihood.

When you do this, you will see the top 4 attacks are:

--------------------------------------------+--------+------------+
Attack Name                                 | Impact | Likelihood |
--------------------------------------------+--------+------------+
Denial-of-service attack against verifier   |  High  |   Medium   |
Denial-of-service attack against key service|  High  |   Medium   |
Display name abuse                          | Medium |    High    |
Compromised system within originator's net  |  High  |   Medium   |

One might suggest or ask "Is this a true relection of a high concern
attacks?"

So I will analyze this a different way as well, by measuring the
likehihood, i.e, how often do I have worry about these attacks?

o Ordered by Likelihood/Impact

--------------------------------------------+--------+------------+
Attack Name                                 | Impact | Likelihood |
--------------------------------------------+--------+------------+
Display name abuse                          | Medium |    High    |
Signed message replay                       |   Low  |    High    |
Chosen message replay                       |   Low  |     M/H    |
Denial-of-service attack against verifier   |  High  |   Medium   |
Denial-of-service attack against key service|  High  |   Medium   |
Compromised system within originator's net  |  High  |   Medium   |
Theft of delegated private key              | Medium |   Medium   |
Body length limit abuse                     | Medium |   Medium   |
Falsification of key service replies        | Medium |   Medium   |
Verification probe attack                   | Medium |   Medium   |
Canonicalization abuse                      |   Low  |   Medium   |
Theft of private key for domain             |  High  |     Low    |
Private key recovery via side-channel attack|  High  |     Low    |
Compromise of key server                    |  High  |     Low    |
Publication of bad key records and/or sigs  |  High  |     Low    |
Cryptographic weaknesses in sigs            |  High  |     Low    |
Use of revoked key                          | Medium |     Low    |
--------------------------------------------+--------+------------+

When viewed in this perspective, one might begin to question the level
of impact and also ask if the attack is detectable and if a system can
recover from such an attack.

One might suggest that all theft has a high impact.

One might suggest that any high occurence attack will always have a high
impact in some form or another as well, unless there is a detection
concept implemented in order to minimize the impact.

For example, one might suggest that if the Signed/Chosen message replay
attacks have high likelihood of occurence, then the impact is high,
rather than low.

So from a DKIM/SSP perspective, I think what might be useful, if we had
a 3rd column, called Detection/Recovery which also rates the
effectiveness of DKIM/SSP to detect and/or recover from the attack.

I know this can be highly subjective, but we can probably use a rating
like:

  MEDIUM - Detectable using deterministic non-DKIM/SSP method
  HIGH   - Detectable using deterministic DKIM/SSP method
  LOW    - Not detectable until reported by human/scoring

By doing it this way,  we get to see an angle for the effective of the
DKIM/SSP protocol and how it can also be assisted by other
recommendations as well and also which ones we really have to worry
about.

This is the rough cut at this, so it could be wrong:

o LOW - Not detectable until reported by human/scoring

--------------------------------------------+--------+------------+
Attack Name                                 | Impact | Likelihood |
--------------------------------------------+--------+------------+
Compromised system within originator's net  |  High  |   Medium   |
Theft of delegated private key              | Medium |   Medium   |
Theft of private key for domain             |  High  |     Low    |
Compromise of key server                    |  High  |     Low    |
Cryptographic weaknesses in sigs            |  High  |     Low    |

o MEDIUM - Detectable using deterministic non-DKIM/SSP method

--------------------------------------------+--------+------------+
Attack Name                                 | Impact | Likelihood |
--------------------------------------------+--------+------------+
Signed message replay                       |   Low  |    High    |
Chosen message replay                       |   Low  |     M/H    |
Denial-of-service attack against verifier   |  High  |   Medium   |
Denial-of-service attack against key service|  High  |   Medium   |
Falsification of key service replies        | Medium |   Medium   |
Verification probe attack                   | Medium |   Medium   |
Private key recovery via side-channel attack|  High  |     Low    |

o HIGH - Detectable using deterministic DKIM/SSP method

--------------------------------------------+--------+------------+
Attack Name                                 | Impact | Likelihood |
--------------------------------------------+--------+------------+
Display name abuse                          | Medium |    High    |
Body length limit abuse                     | Medium |   Medium   |
Canonicalization abuse                      |   Low  |   Medium   |
Use of revoked key                          | Medium |     Low    |
Publication of bad key records and/or sigs  |  High  |     Low    |

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 18:22:23 -0500

----- Original Message -----
From: "Jim Fenton"

> Hector,
>
> Good analysis.  There are a lot of dimensions along which one
> could rate the attacks, so I just had to pick one (well, two).
>
> I had some trouble interpreting from your message whether some
> of the attacks should be rated differently (according to the two
> parameters I used), or not.  Do you have any specific suggestions?

Other than when looking it from an order of occurrence, one might think
that if something happens oftens enough, its a problem or nuisance,
regardless of the severity.

Second, impact is inversely proportion to the detection/recovery.  So if
you have a low detection, you have a higher impact.  A high detection, a
lower impact.

I'm not suggesting to change it, but if I had rated it using this
perspective, I would have made all the High Likelihoods, a High Impact
as well but then adjust the impact column by what you think is the
detection level.

I think you did a good job, and hacking it with subjective rating would
not do much unless it is clear & cut and dry.

So if anything, it might help the reader simply by ordering it.  Some
might want to see it by impact/likelihood, others by likelihood/impact.
I prefer the latter.

-Jim
> Hector Santos wrote:

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Jan 2006 14:29:27 -0800

Hector,

Good analysis.  There are a lot of dimensions along which one could rate
the attacks, so I just had to pick one (well, two).

I had some trouble interpreting from your message whether some of the
attacks should be rated differently (according to the two parameters I
used), or not.  Do you have any specific suggestions?

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sun, 29 Jan 2006 10:37:21 -0800

On Jan 26, 2006, at 4:45 PM, Jim Fenton wrote:

> "likelihood"; let's call it "utility".  The Signed Message Replay  
> attack in section 4.1.5 differs from nearly all of the other  
> attacks in that the attacker can't do everything they'd perhaps  
> like.  If they steal the private key for the domain, they can sign  
> any message they like and send out advertising or objectionable  
> material, etc.  With the SMR attack they can't do that -- they can  
> only inappropriately distribute things that are already signed.   
> This can be bad for the domain's reputation, but if the attacker is  
> looking to sell pharmecuticals, this isn't going to help.
>
> So I marked this attack as "low impact", in part because of its  
> limited utility, and in part because (in accordance with the  
> definitions in section 1.2) this attack deals with individual  
> messages -- it doesn't affect the majority of the messages from the  
> domain, only those selected by the attacker for replay.  Perhaps  
> the definitions need adjusting but I think we need some objective  
> means for scoring the threats.
>
> adjust the document to group consensus, but I wanted you to know  
> where I was coming from.

The Low/High impact of replay abuse depends upon the expected role of  
a DKIM signature, and how a "good" actor can be differentiated from  
that of a "bad."  Challenging this "Low" impact rating is questioning  
whether acceptance of the _message_ or the _signing-domain_ will be  
modified as a defensive measure.  To suggest the impact from replay- 
abuse would be "Low" also suggests an expectation of isolating  
assessments on either a matching email-address or perhaps the  
signature, but not on the signing-domain.  It seems that one should  
consider what this approach entails when resolving accountability  
beyond that of the signing-domain.

With tens of millions of domains, each domain may also support  
hundreds of millions of email-addresses.  There is virtually no cost  
associated with an email-address, nor is there a limit to the number  
of email-address that might be created.  Using the signature itself  
would further increase the assessment database by orders of  
magnitude.  If the recipient finds that resolving beyond the domain  
to be problematic, there would be two choices:

  1) hold the signing-domain accountable for the abuse

  2) ignoring the signature altogether

When a newsletter or promotional ad is distributed well beyond a list  
of subscribers, is this a case of:

  1) an unintended replay by a miscreant

  2) the marketing department relying upon an inability of an  
assessment to differentiate good from bad

When dealing with large organizations, these assessments must be  
defendable.  Many companies already use third-parties to distribute  
these types of messages.  When enough of this abuse becomes common  
place, any such abuse may result in the signing-domain being blocked,  
perhaps out of frustration.

Many domains leak rate restricted abuse from perhaps tens of  
thousands of compromised systems offered access.  Monitoring or  
outbound filters will not be effective control measures.  There are  
any number of messages between friends and colleagues that take the  
form:

Give me your opinion on this.
http://tinyurl.com/1234

Is it practical for a recipient to assess accountability for  
individual messages?  Should the recipient filter on signatures?   
Should the recipient attempt to hold each email-address separately  
accountable?  The unlimited supply of email-addresses would seem to  
suggest that this strategy may be futile.

It seems from the Low impact assessment, you expect the recipient to  
make significant accommodations and to pick and choose messages from  
within a signing-domain.  It would also seem that by even attempting  
to make this type of accommodation, a signing-domain would need to  
constrain the use of email-addresses.  Domains that offer email- 
addresses like list-master will be in greater peril unless each  
posting changes this email-address.

-Doug

-Doug