[ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

[MH Michael Hammer (5304)]

Comments inline

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.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