J D Falk wrote:
At the meeting on Tuesday, I suggested that one way to settle the d= vs.
i= debate would be to document the many overlapping yet divergent likely
use cases -- and was promptly asked to do so. Hooray for volunteerism!
I think the threat modeling may be yet another instance where we're all
taking past each other because we have different threats in mind, so
(unless there's stringent objection) I'm going to include
threats/concerns in that document as well.
Right now I'm on a flight back to Colorado, then on vacation for a few
days, so the questions for this project will show up next week. Feel
free to send me any additional thoughts in the meantime.
J D,
First I would like to say that I welcome this project of yours. If will
finally help focus attention to the security issues I and many others
highlighted, then this is good news.
When I wrote the (now expired I-D) I-D DSAP (DKIM Sender Authorization
Protocol) draft:
http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://www.isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt
the main reason was to officially highlight the concerns and hopefully
they would be considered for SSP. I was not really interested in
competing or stepping on anyone's toes, but only to highlight the
concerns. I decided not to follow up on DSAP and support SSP when Jim
did consider them for the most part, in more complex ways, but it was
enough to satisfy the key concerns outlined in DSAP.
Before I was encouraged in writing the I-D, I outlined it with a
PowerPoint presentation, where it was converted to a web presentation:
http://www.isdg.net/public/sap/dsap.htm
The presentation might help summarizes the issues.
If you do look at these documents, please view it not a proposal for a
new DSAP protocol, but to extract the general considerations.
The DSAP work was based on working out the boundary conditions for all
possible DKIM results. This was done back around the 2005/2006 time
frame. It help highlight what can be eliminated, what can be folded and
also help highlight the complexities as well. You might want to look at
this August 2005 message which help frame the discussion on SSP and how
it relates to DKIM:
http://www.imc.org/ietf-mailsig/mail-archive/msg02046.html
In fact, on that time frame, there were many really good key security
discussions regarding SSP:
http://www.imc.org/ietf-mailsig/mail-archive/theads.html#02046
DSAP considered the entire flow of whats possible, including payload
considerations to help address optimization. This is one reason I
personally had a problem with the SSP lookup steps outlined in RFC 5016,
but it wasn't a big concern related to the overall questions DSAP addressed:
Ultimately, DSAP addresses the following fundamental security questions
about DKIM:
* Does the domain ever distribute mail?
* Do you expect the mail to be unsigned?
* Do you expect to sign all mail?
* Is your domain the exclusive signer?
* Are 3rd party signers or signatures allowed?
* Are 3rd party signers allowed to strip your original signatures?
Each of security concern is based on whats realistically possible in
deployed pure DKIM signer and DKIM receiver only world. Nothing was
left out, I refrained from subjective thinking, non-heuristic, purely
technical considerations on the automatic state machine possible
conditions for DKIM.
Another relative viewpoint of the above is to relate them to current
conditions in the today's world and this might help to determine the
relative effectiveness of a SSP or DSAP or any other Originating
domain-based policy protocol. In principle, a receiver will see the
following boundary conditions:
(1) Mail arrives with no signature
(2) Mail arrives with valid 1st signature (1PS)
(3) Mail arrives with invalid 1PS
(4) Mail arrives with valid 3rd signature (3PS
(5) Mail arrives with invalid 3PS
One example:
A domain exclusive "Only I always sign" 1st party signing policy.
Using a simple FUZZY LOGIC classification model:
+1.0 -> 100% good, no false positives
+0.5 -> 50% not sure, everything look good, hash failure
0.0 -> indeterminate
+0.5 -> 50% not sure, something is wrong
-1.0 -> 100% bad, no false positives
Based on this stated policy, you can rate the results:
-1.0 (1) Mail arrives with no signature
+1.0 (2) Mail arrives with valid 1st signature (1PS)
-/+0.5 (3) Mail arrives with invalid 1PS
-1.0 (4) Mail arrives with valid 3rd signature (3PS
-1.0 (5) Mail arrives with invalid 3PS
Analysis:
First with the 100% reliable zero false positive failures:
-1.0 (1) Mail arrives with no signature
-1.0 (4) Mail arrives with valid 3rd signature (3PS
-1.0 (5) Mail arrives with invalid 3PS
There should be no question that these are 100% violations of the
domain's stated exclusive "Only I always sing" policy. Signatures are
required and no 3rd party signing is expected. Therefore there should no
ambiguity from an programmatic automated thinking process on what
classification these results belong in - these are candidates for
immediate rejection.
Second, the 100% reliable zero false positive success:
+1.0 (2) Mail arrives with valid 1st signature (1PS)
Again, there should no question that this is a "DKIM Complete" and "SSP
complete" message. It should be be classified as a candidate for
acceptance.
Note: In the Threat Analysis discussions leading up to
RFC 4886, I believe it was a consensus that the only
reasonable possible threat for a 1st party valid signature
is internal theft or compromise of the owner's DKIM hashing key.
and third, that leave us with the indeterminate result:
-/+0.5 (3) Mail arrives with invalid 1PS
It is indeterminate because there has been no confidence in what to deal
with failure.
It could be a +0.05 in the sense that the DNS records all look ok, but
there was hashing failure. One of the reason we have a bh= body hash
was to help address this scenario where there might be a simply message
body integrity issue.
It could be a -0.05 in the sense that something else went wrong,
NXDOMAIN, missing headers, something else probably shouldn't happen like
the more understandable body alteration issue.
In either case it is a indeterminate condition in the same, it is not a
100% zero false positive condition.
The security threat here is that unless there is guidance for
indeterminate conditions, bad guys can exploit DKIM by intentionally
creating DKIM signature that will fail. In other words, just throw in a
junk hash.
and finally, for this fuzzy condition, this leads up as do why I always
thought the DKIM "ignore if failure, view as unsigned" can both be
useful but also problematic.
If we follow RFC 4871 DKIM recommendations in classify failed DKIM
signatures as unsigned then the above analysis changes:
-1.0 (3) Mail arrives with invalid 1PS -> Promoted to no signature
Because it is was promoted to no signature, the exclusive policy will
promote a rejection classification.
This can be viewed as both good and bad:
- good: a decision has been made.
- bad: This increases the potential for false positives.
In summary, we just analyzed the really strong exclusive "I always sign"
policy. The same can be done with the others to create a decision tree
with +/- 1.0 zero false positive conditions and also fuzzy +/- 0.5
indeterminate unknown false positive conditions.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html