Approaches to system design - Marketing vs Security and why MASG should not be standards group (was: Re: MAAWG whitepaper draft)

On Mon, 13 Dec 2004, Chris Drake wrote:

> On a different note: It's amusing to see other people starting to cry
> foul now that the lack of integrity and honesty of people involved in
> "white paper writing" is getting more overt.  I urge all of you to not
> accept this blatant dishonesty: if something's broken in
> SPF/DK/SID/etc, state so honestly and upfront and stop sweeping all
> the nasties under the carpet. 

Since I never could keep my mouth shot when I see that there is a problem,
I certainly was quite clear that both SPF and DK have serious issues and 
SID even more so then the rest. Meng's point of view however seems to be 
if we put it all down its one big melting pot, maybe it'll work out for 
the good (and in the mean time by appeasing everyone, it makes everyone 
happy) and that result would be easier to market no matter what one's 
needs are and lead to faster adaption.

Security guy's point of view is that you have to get it done right at each 
layer so it could work on its own because melting pots have high chance of 
having not immediately seen security problems (not only problems for each
layer become global ones but some problems are result of such melting of
of multiple layers) that are later exploited and result is that entire 
system is likely to be vulnerable and not easily fixable.

A practical example of the "melting pot" approach is the one Microsoft 
takes with its products, the result is that they can quickly create a 
product that can appease to large audience and that is easy to market, 
but later those who use it are faced with serious security issues in
such a product that takes long time to get fixed (if at all possible 
without complete redesign) and you all can guess that widespread of 
viruses and zombies is the direct result of that.

Now because of the above issues and because we're after all dealing
directly with email security (and not with some general new protocol
or system), the 2nd approach of making sure each layer is secure just
on its own is the best one (even if it takes longer to produce results)
and I do still believe we can do both session authentication and 
cryptography so it works on their own - obviously that means more 
technical work and not ignoring the issues and replacing it with
politics and marketing tricks to make it appear that all is good.

Also for those interested you might notice that melting pots is always
the approach those in the marketing would take while per-layer security
is approach taken by the technical people. IETF is up until now been
controlled by technical community and so IAB and IESG were probably not 
super favorite of the MARID and also had been slow to decide if they
want to work on MASS which potentially has the same problems.

Its not surprising that seeing that SID and similar marketing-driven
approaches are not being seen favorably by IETF, some are now starting 
to talk about creating new "Messaging Accountability Standards Group"
(MASG) to push such designs through on their own ignoring technical and 
security flows of the melting pot system. I urge such people who favor 
new standards group as next step for SPF to reconsider your views and 
listen to the advise given in good faith by the experienced technical 
community and work on fixing current problems instead.

And I believe strongest would be a combination of skills found in each
group - that means SPF should continue to be focused on experimenting
and initial design and then finishing touches and technical review for 
those designs before becoming standard should be done by IETF (which is 
strongest there as it has good understanding of many issues involved 
including not only email but dns and others). Then it goes back to
SPF which has understanding that design is not only about creating
standards but marketing this standards and supporting its initial 
deployment (this IETF always failed to do for its standards and
leaves this part up to companies that worked on such a standard).

As such my view is that MASG should stand for "Messaging Accountability 
Solutions Group" it should NOT be a standard creating body but a something
that helps in the R&D and marketing for FOSS driven initiatives where
there is no direct corporate support to do either.

---
William Leibzon, Elan Networks:
 mailto: [email protected]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/