Doug,
I agree with you 100%, but this is how my brain is wired (excuse my
chemical engineering hat):
Think of a perfect circle used for monitoring variables of a process,
i.e. pressures, temperatures, etc. A perfect circle represents
equilibrium and steady state operations. Any deviation of this perfect
circle shape means there is a difference, a "delta" in the system.
Could it be a faulty value? A leak? A built up of corrosion in
heterogeneous material interfaces or curvatures?
Think of a perfect harmony, a song, a tune mapped to the health of your
blood, urine, etc. Any deviation in the chemical levels creates kinks,
squeaks in the tones of the harmony.
Take your car. You hear a strange noise in the engine you never
expected, maybe it is shaking a lot. Most likely there is something
going
on or just the beginning of things to come. A tune up?
etc, etc.
These are basic fault detection designs based on "Expert Systems"
methodologies.
Same with any expected behavior of any "Process" including the extremely
simplistic email and the proposed DKIM protocol.
Lets look at Cisco's DKIM flow charts and presentations on how
DKIM will work. Those perfect graphs are based on "steady state"
operations of the protocol.
The question is, what happens when there is a deviation of the protocol
operations. How do you handle it? What does it mean? Is it a broken
client? Is there a bug? Is there a terrorist spoofing a domain? Did a
terrorist put poison in your message?
Whatever happen you might not know right away, but you do know there is
problem. An alarm has been raised.
Lets go ahead and apply a trust system.
We can say a slight torque on the perfect circle is not a concern. We
still "trust" the system will not blow up. Maybe we can plot an inner
and outer circles representing boundary conditions (acceptable or
undesirable limits). If any part of the twisted circle touches the inner
or outer circles, then you no longer "trust" the process - something
might blow up!
The problem is that one trust expert (process engineer) might say:
"No Charlie, we are still ok. Nothing to worry about
yet. Tolerances are built into the system."
And another trust expert may say,
"Well Larry, we should consult the operations
manual and call the 800 number to see what
vendors have to say."
And yet another trust expert might say:
"Excuse me Larry and Charlie?. But why isn't it adjusting
itself back to steady state?"
Suddenly, alarms ring and the system blows up!! <g>
So even thought we can always apply trust on top of an expect system
concept to any system, it will always be hindered on judgment calls
based on the black art of knowledge extraction. You can learn from it,
of course.
But all of it will always need to follow an expected mode of operations
and any deviations from this expectation is where and when you begin to
measure and protect the system.
I didn't want to muddy the water critiquing hard work put into the TA.
But that analysis was predominately based on "external" attacks. There
was a fundamental neglect on the attacks based on the breakdown of
proper protocol usage and this was highlighted with the incredible mind
bogging revelation of the "near" exclusive policy.
So it really doesn't matter what you have for a trust system or any new
idea for DKIM attributes, opaque-id or anything else. If we want to go
there, lets do it.
But it still needs to follow an expected and consistent protocol
behavior. If your first level of protection isn't based on fundamental
principles of following a steady state expectation of a protocol, then
we have issues.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>; "Frank Ellermann"
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Sent: Thursday, February 02, 2006 7:30 PM
Subject: Re: [ietf-dkim] Re: New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks
On Feb 2, 2006, at 6:59 AM, Hector Santos wrote:
As with DKIM the only real exploit is a PASS from a white-listed
source.
The issue of PASS is true. Why should we trust it?
DKIM is about restoring trust for transactional emails. A domain
should be assumed untrusted until otherwise vetted as trustworthy.
When the signature is verified, the white-listed source is being
trusted. However, white-listing a signing domain may include both
trustworthy and untrusted users or signing applications. There
should be a means where the signing-domain is able to offer guidance
with respect to which internal sources are trustworthy and which are
not. After all, a single signed message can be replicated widely and
wreck havoc. Such havoc may impact the domain's trusted status.
But we don't have must more we can do here but to apply or augment
optional and non-standard tracking concepts.
A bit in the key verifying the message's signature can note whether
the specific internal source for the message is considered
trustworthy. Such an assertion could help sort out trusted and non-
trusted messages. The signing domain would be motivated to protect
their own trustworthy status and ensure messages obtaining a
"trusted" status are indeed from trustworthy sources. It is
important to minimize the amount of "trusted" abuse allowed to slip
through. This concern would be due to evaluation costs, as this
would be based upon message content. :-(
However, what you want to make sure you don't allow fall thru the
cracks are the mix policy and protocol inconsistencies, and that
might include mixing DKIM with other methods as well at the
implementation level. But at the very least, the protocol level.
Just one small aspect of a violation of trust would be an
"inappropriate" use of header fields. Even this apparent
inappropriate use of a header field would depend upon the role of the
signing-domain and whether the signing domain is also asserting the
message to be trustworthy. For a typical list-server, none of the
list's messages should be marked as trustworthy. Perhaps messages
from the list's administrator could be marked as trustworthy, in
which case headers will likely not be an issue.
DKIM is independent of the message envelope. This independence means
that DKIM can _not_ be used to abate spam. Third-party signing
policies will likely play little, if any, role in evaluating a
violation of trust. When the signing-domain is trustworthy (third-
party or not) and indicates the message can be trusted, the email-
address that appears in the header will likely be of little concern,
unless or until there is a report of a violation of trust. Those
domains considered trustworthy should also held accountable for any
criminal acts that they both sign and _mark_ as trustworthy.
Not marking the message trustworthy should mean the message is simply
treated as not signed, irrespective as to whether the domain itself
is trustworthy.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org