----- Original Message ----- From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> 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