Comments inline
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of hector
Sent: Monday, June 15, 2009 7:38 AM
To: Charles Lindsey
Cc: DKIM
Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures,
was
l= summary)
Charles Lindsey wrote:
And every list will be diferent, so we need to look at real
examples.
And
by a strange coincidence, we have just seen a concrete example on a
list
well-known to all of us.
Yup, I am going to enjoy reading this thread.:-)
Me too. Popcorn in hand (figuratively speaking).
Speaking as a commercial List Server product manufacturer, its simple:
The only time a list server should resign is when it broke an original
valid signature for the purpose of restoring the mail integrity of the
original domain message owner and author with an original DOMAIN
intent
to sign mail. It should never sign a message that a DOMAIN never
expected to be sign or knew nothing of it and It should NEVER, EVER,
NEVER resign a broken DKIM message.
So you are absolutely against 3rd party signatures unless the 3rd party
broke a first party signature?
My understanding has always been that anyone who handles a message can
sign and thereby take responsibility (whatever that might mean) for the
message they are signing.
The basic overall problem is we are trying to make something with
an
POLICY framework. It won't work well, just don't see it.
And the 4871 flaw of promoting FAILURE to never sign status
complicates
the handling issues. The only time that FLAW makes sense is when
you
have POLICY and since SSP was an integral part of DKIM, you can see
the great logic in the BROKEN=NEVER SIGNED mandate in the
specification.
I have to disagree Hector. For better or for worse, SSP was never an
integral part of DKIM. It is layered on top of DKIM. Those that wish to
publish a policy (whether it was SSP or ADSP) can do so. Those that wish
to check and act against a published policy may do so. Others may choose
to ignore SSP/ADSP whether as a potential publisher or a potential
verifier. While I am a firm believer in the need for organizations to
have the option of publishing policy, I do not view it as "an integral
part of DKIM". To do so would require one to advocate publishing policy
as "MUST" rather than "SHOULD" or "MAY".
But when don't have POLICY than that mandate is FLAWED - period.
BROKEN=NEVER SIGNED mandate in the specification. If an organization
chooses to assert they sign all messages and BROKEN=NEVER SIGNED then
the logical conclusion is obvious.
You need a policy framework to help disseminate what was expected and
what was not expected. You are left with a guessing game - is this
FACEBOOK message a spam or a message vouched by Dave's server?
It appears to be a spam vouched for by Dave's server.
Should
people trust it because Dave's broadcasting server signed it?
What does trust have to do with it? All I know is that Dave's server
signed it and Dave thereby takes responsibility for it. So Dave.....
what does your taking responsibility for it mean?
Did the
message have a valid signature and Dave stripped it or was a invalid
and
he stripped and replaced it anywa? It speaks volumes to the lack of a
POLICY based framework. It should NEVER be a source of new SIGNING
when it was never there to begin with and/or expected to be there by
the
original domain - bad guys will no doubt exploit this as you just
seen. I thought his FACEBOOK think was legitimate for a second, that
someone here was putting together a DKIM social network. Can
imagine
the layman user? Is he not a RISK?
I'm surprised Hector. It really took you a second to decide it wasn't
legitimate?
IMO, The list server should NOT sign unless the mail was valid with a
DKIM signature and its going to break it, thus the need to restore a
DKIM message - not create one.
Au contraire. What you describe leaves a vector for attack a mile wide.
Break a signature from the original domain and then sign with some
random domain. You cannot accept one signature as a substitute for
another (broken) signature. Each signer stands on their own merits (or
lack thereof.)
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html