Subject: RE: [ietf-dkim] DKIM and mailing lists

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Jan 2006 19:24:58 -0800

List traffic is one of the few cases where the recipient has
affirmatively opted in to receive it. 

I agree with Mark, mail agents should be processing identified list
traffic in a very different manner to ordinary unsolicited traffic.

We need to define rules for a compliant mailer so mailing list authors
know what to code to. But the mailing lists that are going to bite us
are the legacy ones that are not in compliance.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Wednesday, January 18, 2006 5:59 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] DKIM and mailing lists
> 
> On Wed, Jan 18, 2006 at 11:38:53PM +0100, Eliot Lear allegedly wrote:
> > Mark Delany wrote:
> > > Given the religion, I wonder whether both are entirely reasonable 
> > > and leave the choice to the particular list implementor.
> > >   
> > 
> > I know I don't want to take on the argument of which is 
> reasonable so 
> > applying guidance for both and for clients in the face of both is 
> > important.  Particularly for whether or not you protect the Subject 
> > line and how at all to limit length, and or resign.  There are some 
> > serious UI issues there.
> 
> The very early thinking back at DK-00 was that a 
> participating list might sign List-ID. The idea being that 
> List traffic is distinctly different and that a verifier/UA 
> might sensibly treat such traffic differently in the presence 
> of a List-ID. Subsequent revisions went down the path of 
> generalizing that to Sender.
> 
> In retrospect, I'm not sure I'm a fan of that generalization 
> as List traffic is so different that it need not be squeezed 
> into a generalized category that otherwise is almost 
> completely absent in real-life traffic.
> 
> 
> Mark.
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
> 
> 

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 19 Jan 2006 03:10:31 -0500

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> affirmatively opted in to receive it.

Which presents the #1 design change to a list subcription processor in
order to close a DKIM/SSP threat entry point.

> I agree with Mark, mail agents should be processing
> identified list traffic in a very different manner to
> ordinary unsolicited traffic.

I basically see three basic models:

 - address expander, From, Return Path remains the same.
   This offers passthru (no content change) operations.
   Typically, no separate storage.

 - address expander with "content change", From, Return
   Path remains the same. Typically, no separate storage.

 - Address expander with content change and return path
   to a new List Management address agent.  A separate
   storage is used to offer extended list features.

John calls them Thin vs Thick.  Cool, but they are really list expanders
vs list servers because list expanders can be part of the SMTP process
or POST SMTP mail filter process, which typically have nothing to do
with a possible separate "List Server" process and/or application.

> We need to define rules for a compliant mailer so mailing
> list authors know what to code to. But the mailing lists
> that are going to bite us are the legacy ones that are
> not in compliance.

The design issues we see for our List Server are:

1) Controlling the Subscription process to regulate restrictive DKIM/SSP
policies.

This basically means the NEVER, EXCLUSIVE policies, the most beneficial
features of DKIM/SSP, will be used to blocked subscription attempts by
these specific domain SSP declarations.  The list server must offer this
if it wishes to assist in securing domains.  I have more about EXCLUSIVE
in more detail below.

2) For us, the List Server will not perform any DKIM verification. Only
SSP policy verification. Our SMTP inbound processor will perform this
DKIM verification job.

3) New options to control the type of DKIM/SSP messages allowed.

This could be a list of SSP declaration to be allowed by the LS mailing
list setup.

In my opinion, I don't realistically see DKIM domain implementaters
interested in protecting their interest allowing "relaxed" DKIM SSP
domains to be used on public mailing lists. It will promote exploitation
with obviously broken integrity issues.

Nonetheless, we do see a design that takes into account relaxed
policies.   The bottom line is what the domain declares for his SSP.

Sender-Signing Policy (SSP):

         NONE (no policy)
    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

- NONE

List Server MUST not sign the message. Period!  It is can what it wants
to the mail. But it must NOT sign it.

May be part of restrictive SSP policy list for List Server if the
mailing list owner REQUIRES all domain mail to be DKIM compliant.

- WEAK (signature optional, no third party)

May be part of "Allowed SSP policy" list for List Server.

List Server MUST not sign the message. If the message is signed, options
should offered to avoid content change.

- NEUTRAL (signature optional, 3rd party allowed)

May be part of "Allowed SSP policy" list for List Server.

If the message is signed, options should be offered to avoid content
change.  If content change is required, LS must resign message as a 3rd
party.

If the message is not signed, the LS may choose to resign the message as
a 3rd party.

- STRONG (signature required, 3rd party allowed)

May be part of "Allowed SSP policy" list for List Server.

With the required signed message (SMTP verified), options should be
offered to avoid content change.  If content change is required, LS must
resign message as a 3rd party.

- NEVER  (no mail expected)

The LS Subscription Process should pre-empt this highly restrictive
DOMAIN SSP declaration.  The subscription process must handle both
interactive and automated subscribe attempts.  The automated attempt
should be handled by the SMTP DKIM verifier.

- EXCLUSIVE (signature required, no 3rd party)

May be part of "Allowed SSP policy" list for List Server.

Overall, similar to NEVER, the EXCLUSIVE policy should be subscription
restricted.

However, if the LIST SERVER can behave in a "thin-like", address
expansion, passthru "no mail content change" manner, then an EXCLUSIVE
policy may be used for the mailing list.   This brings up another
potential SSP declaration that identified a different sender.  This is
closer to a STRONG policy but more about a particular 3rd party service
taking control of the signing process. It might have to break SMTP rules
by lying who the sender actually is.  But as long as it is legal
relationship and contract between domain owner and the actual signer,
and it is consistent DKIM/SSP protocol, I don't see a problem with this.
If any potential bounce back is required, the signing entity must be
able to contact the domain owner.

For this reason, the LS should probably restrict subscriptions by
exclusive domains unless it is going to take complete ownership of the
message and that means the List Server manager having access to the
Domain Signing Keys.

- USER

We keep ignoring this user policy since it really raises the levels of
issues.  I am particularly not interested in signing "user mail."

In short, we see that its all possible to redesign the framework around
the strong security capabilities DKIM/SSP has to offer.  There are
complex considerations, but overall doable.

Even if a legacy LIST SERVER is DKIM/SSP ignorant, the DKIM/SSP
verifiers will control the situation especially for the restrictive
policies.  Remember the highly restrictive domains will always be
protected with compliant SSP verification. With relaxed policies,  LS or
not, they will be also be problematic with a much lower "trust" value
behind them.  However, the worst the legacy or non-DKIM compliant LS can
do is to break the integrity of the message.

To me, this integrity issue is not the LS server problem, but the domain
owner who has allowed it to happen.  He should be made aware of this
possibility if he chooses to use his relaxed domain blindly. He is the
one that will be playing with fire by using relaxed DKIM domain policies
in "open-ended" promiscuous ways around the net, joining mailing list
here and there with otherwise "marked" domain that will raise the
eyebrows of DKIM compliant systems.  In my opinion,  he should not
expect any security enhancements and scratch his head to wonder why his
domain has become "black listed" due to over abused by DKIM relaxed
domains exploiters.

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

---

From: Earl Hood <[email-masked]>
Date: Thu, 19 Jan 2006 14:25:39 -0600

>     o=.  NEVER  (no mail expected)
 ...

Wouldn't be easier of the signer can assert a role so such checks
are not necessary by a list server?  If the list server makes no
assertion against an (RFC-2822) originating address, it should be
able to sign all messages it distributes.

This would avoid list servers having to do SSP checks on each message
and avoid the problems of bad implementations getting the logic wrong
on when to sign and not to sign.

 From an audit, and accountability, perspective it would be useful
that all list server software DKIM sign messages regardless of
any originating-address-based SSP.  This way, list server software
can always assert what messages it distributes out regardless of
the originating author/sender.

--ewh

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jan 2006 12:50:07 -0800

Earl Hood wrote:
> are not necessary by a list server?  

No. SSP is not for signed mail, it's for unsigned mail.

> If the list server makes no

Correct. Nothing needed to provide this, though the i= isn't explictly
saying what "role" (binding) it's providing (if any).

> on when to sign and not to sign.

Receivers in general only need to do SSP if the message is unsigned.
List servers are no different.

> the originating author/sender.

Yep. That would indeed be very nice.

		Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Jan 2006 16:42:55 -0500

> No. SSP is not for signed mail, it's for unsigned mail.
If it's a third party signature you still need to check SSP for EXCLUSIVE 
policy.

> List servers are no different.

ditto.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Jan 2006 14:50:46 -0800

> If it's a third party signature you still need to check SSP for EXCLUSIVE 

That doesn't alter what I said. You fundamentally cannot get out of
making checks if you're missing a (first party) signature. That's
SSP's purpose in life.

		Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Jan 2006 18:23:57 -0500

> making checks if you're missing a (first party) signature. That's
OK.  Then I misunderstood what you said, because I agree with that.

Scott K