----- 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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-Jim
Hector Santos wrote:
----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
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
_______________________________________________
ietf-dkim mailing list
http://dkim.org