----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
List traffic is one of the few cases where the recipient has
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
_______________________________________________
ietf-dkim mailing list
http://dkim.org