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" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: <[email protected]>; "Frank Ellermann"
<[EMAIL PROTECTED]>
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
