Subject: RE: [ietf-dkim] Proposal for specifying syntax andsemanticsformultiple signatures

From: <[email-masked]>
Date: Mon, 3 Apr 2006 09:59:43 -0400

The new found unchecked DKIM junk will always be with us.
DKIM base is not about determining acceptance policy, its about
identification of where the mail was handled last. SSP is an
authentication methodology, not part of the base. 
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Sunday, April 02, 2006 1:04 PM
To: Barry Leiba; [email-masked]
Subject: Re: [ietf-dkim] Proposal for specifying syntax
andsemanticsformultiple signatures

----- Original Message -----
From: "Barry Leiba" <[email-masked]>

> Any decisions about the quality of the message or the goodness of the
> source are made by the verifier, POSSIBLY using the information
provided
> by DKIM as input, but not directly resulting from DKIM.

So you are creating a functionl specification and mandate, to mold local
policy on how to NOT handle the new found unchecked DKIM junk?   You got
to
be kidding that you will control this market.

>
> <chair>
> In particular, any attempt to include that sort of information in DKIM
> is explicitly out of scope for this working group.
> </chair>
>
> Barry

I thought we have moved on to SSP?  SSP is not out of scope. Correct? I
am
referring to SSP to help answer many of these questions being raised,
including this thread about nth signatures and ambiguious mandate on how
it
should be "Intepreted!"

It is a moot point what a nth signature means if a nth signer was not
authorized by the domain owner to resign it.  For some reason, that
isn't an
important consideration.

This DKIM-only simplicity is an extremely harmful mandate to impose on
verifiers, specifically vendors who such as us who need to implement
this
stuff and convince customers this stuff has any value or payoff.

I am not just making this up, you know?  I am not trying to be
ANTI-DKIM,
you know?  I want it to work too.

My concern is that we will have a growth DKIM-only systems out there
creating a deluge of high volume invalid, fraudulent DKIM messages with
no
controls in place and because of this weak and neglectful half-baked
incremental design approach, we will have two markets to deal with:

    - the DKIM-only market with tons of fraud
    - DKIM market with some unknown augmented technology only privy to
      a few here that isn't here yet.

You guys are mandating a technology that is quite frankly, infested with
flaws. You want to tell us what it means, with what seems to me a
careless
attitude or lack of a clear vision (intentionally made vague I suppose)
for:

    - determining how to clearly implement it,
    - what scalability issues will come from it,
    - and completely ignore the all error and worst case scenarios.

Where is the error analysis in all this? None!

Where is the system engineering in all this?  None!

Sorry, I don't have any misunderstanding of what you or Dave expect DKIM
to
be.  I understand very clearly what "yall" trying to do.  But it is
flawed
and dangerous and you have no evidence nor shown any proof to the
contrary
to suggest a DKIM-ONLY implementation is going to be safe in a widely
adopted network.  I see no consideration in handling predictable
scenarios
of being bombarded with DKIM signed mail - good or bad.

I put together some diagrams of a highly efficient DKIM/SSP verifier
system
that protects the DKIM DOMAIN owner from exploited usage of domains.  It
is
based around SSP - a simple consideration that resolves many of the
current
signing questions.

See

http://www.winserver.com/public/ssp/ssp.htm

Hopefully this will make some sense.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

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

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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 3 Apr 2006 10:18:13 -0400

----- Original Message -----
From: <[email-masked]>

> The new found unchecked DKIM junk will always be with us.

And if DKIM is expected to be adopted, those new found unchecked DKIM junk
numbers are expected to be high.   Its quite simple:

  DKIM-BASE RULE:

  - Mail Has DKIM-Signature Header:

        VALID   -->  PASS TEST
        INVALID -->  IGNORE/CONTINUE

  - Mail has no DKIM-Signature Header:

        CONTINUE

So you have two types of continues:

    CONTINUE-DKIM-FAILURE
    CONTINUE-LEGACY

Our problem in the SMTP industry is that we can not make heads and tails
with legacy operations.

DKIM helps raised the bar. Its a new level of expectations. If a message has
a "purported" signature, abeit a failed one, this is not a LEGACY
operations.  This would be a new era of incredible and valuable information
that can be used to help protect the exploitation of domains. In short, it
is fundamentally illogically to suggest in the SMTP world:

   CONTINUE-DKIM-FAILURE is equal to CONTINUE-LEGACY

> identification of where the mail was handled last.

So its a TRACE system now?

> SSP is an authentication methodology, not part of the base.

Hmmm I believe the technical model is closer to:

 1) DKIM is an Authentication concept because it help validate
    the integrity of the message object.

 2) SSP is an DKIM signature Authorization policy concept.

The DNS server is your public central server. The idea is that the bad guy
does not have WRITE/DELETE access to your DNS KEYS.  It has only READ
ACCESS.  Having WRITE/DELETE acess would be a protocol flaw or threat.