Phillip,
You could always proposed an extended DKIM implementation that supports a
A/R protocol.
If I read you correctly, I could agree that it needs to be open-ended
interface. But I don't agree it has to be dependent on any existing A/R
concept. I think you can use these a model to develop a generic interface,
in fact, you might want to consider doing this from an OPES standpoint
(which is an IETF WG).
For example:
result = OPES_DKIM(data) or
result = OPES_AR(data) or
result = OPES_DKIM_AR(data)
The fact is, it would be a major mistake to believe a system will depend on
only one method. The technology is too new and yet to be proven and all
these will most like be best modeled a "Plug and Play" solution. I believe
most vendors software allows for this, Exim with its ACL, SendMail with its
Milters, MSE with its Sinks and Wildcat! with its callout pcode system.
Santronics is going to offer all the "practical solutions" that have some
momentum to its customers and operators. They will choose how the puzzle
will fit. If they want to use SPF with DKIM, they will be able to. If
you want to use CBV, DNSRBL, SENDERID or whatever is added, they will be
able to do so.
So if they want to use Phillip's new OPES_VERISIGN() proxy, so be it.
Make it happen.
Here is a tip: Don't lock it to DKIM only. Make it work as a generic A/R
concept with maybe considerations for the current protocols with momentum
for:
SPF
DKIM
SENDERID
But to have DKIM be dependent on it, well, I think it is a bad business move
and from my end, I will have trouble with this approach to have DKIM locked
into a A/R system. It has to be optional.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
Ridiculous or not, I'm getting a lot of them these days. If I were a
spammer, I would be very interested in intercepting valid signed
messages and turning them into ASCII art in a way that preservesd the
signature.
Having said that, I'm not sure we should worry about it. I
don't have
a very high opinion of the technical competence of the average user,
but I think the idea that most ASCII art messages are not to
be trusted
is something that we can socialize widely.
I have been spending some time looking at why crypto systems fail. There
are two reasons that are relevant to this argument:
1) The system has a major flaw that is easily exploited by an attacker.
2) The system is never deployed because it is over-designed and too
cumbersome to use.
Think for a moment about the crypto systems that are in most widespread
use; SSL, WiFi, Kerberos, etc.
Every single one of the successful crypto systems had a major flaw, SSL
1.0 was deployed and then broken 15 minutes into the disclosure of the
algorithm. SSL 2.0 had major problems. But SSL 3.0 was fixed and is the
best tool we have deployed today.
WiFi is an even more on point example. The biggest problem with WEP is
not the security vulnerability, it's the fact that the spec is too
difficult for people to turn on and so less than 50% of access points
are encrypted.
I am not arguing for negligent design here, just some perspective. I
think that we need to think about what happens if ASCII art is used as
an attack on a large scale. The worst case scenario I can think of is
that everyone turns off nowsp and switches to simple.
Another possibility is that we develop a third C14N algorithm in the
group to supplement the existing two. Or maybe we modify checking of
nowsp to make it MIME aware in some degree or perhaps we think up
another fix.
The point is that we have to walk a fine line here. We should make the
scheme as robust as possible but we have to understand that if we
over-do it we risk a system that is too brittle. Its like
shove-ha'penny, you want to go as close to the edge as possible without
falling off the cliff.