Re: Fwd: Re: [ietf-dkim] Introducing myself

Charles Lindsey wrote:
> On Wed, 06 Dec 2006 20:25:39 -0000, John Levine <johnl(_at_)iecc(_dot_)com> 
> wrote:
> > As I recall, we agreed that is specifically not a goal of DKIM.  If
> > you want a signing scheme designed to survive all sorts of hostile
> > gateways, there's already S/MIME.  The limited c18n in DKIM is
> > intended to survive only the most common sorts of transit relays.
> Unfortunately, S/MIME already suffers from exactly the same 
> bug^H^H^Hfeature, which is why I was surprised to see that DKIM has 
> followed that same broken path.
I don't believe it did not follow the same path. Its one reason we are 
interested in its completion and implementation. The MUA version is one 
that was easily seen as broken simply because MUA has no control on 
backend server hosting systems.  That was a no-brainer.
> DKIM will have no effect on the present spam/phishing/malware scene 
> unless it is widely adopted. 
I disagree with that premise. DKIM can have a very highly effective 
domain protection potential depending on the domain signature signing 
policies.  Its not a cure all, but can be highly effective in 
eliminating the obvious failures.  The DSAP I-D illustrates this:
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt

> It will not be widely adopted unless it is seen to be robust.

which says that exclusivity does plays a big role in DKIM success. 
Relaxing policies has always failed (been exploited) protocols with 
relaxed provisions in practice.  This idea is like adding $25K in home 
security, yet, you leave a key under a potted plant on the porch.
> In particular, it will not be adopted in countries 
> (esp those in Asia) where the character sets used are totally unlike 
> ASCII if it can only be made to work by forcing everything to be sent as 
> 7bit. 
You're assuming MUA are involved. Right? This all can be 100% 
transparent if we keep DKIM out of the Presentation Layer.
> They just cannot survive in an environment where textual messages
> 'on the wire' cannot easily be read in that form. They will just resort 
> to "send 8bits anyway" which is already happening, even with headers, to 
> a large extent, because 99.9% of the time it actually works like that 
> without problem.
Ok, if a transformation has to be done, then the DKIM owner will know 
how do deal with this when it finds out that a failed outcome can not be 
avoided.   Or maybe they have worked out a route so that there will be 
known middle ware who will alter and but also resign the mail.  As long 
as the final system validates and authorizes the domain signature , its 
fine.  You can't use certain technologies in all systems and that 
applies in many areas.
> That is why the parallel EAI effort has been mentined so often in these 
> discussions, because it is pulling in exactly the opposite direction to 
> this WG, and it is the Chinese and the Japanese who are pulling the 
> hardest.
I don't see how it applies and IMV, its no different when there are 
other mid-stream transformation requirements and a DKIM owner who is or 
not aware of it.  Regardless of the transformation requirements, whether 
its for Americans, British, Chinese or Martians, DKIM still needs 
knowledge of any mail integrity change and signing/resigning entities.
===
HLS


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html