On Dec 21, 2007, at 7:43 PM, Hector Santos wrote:
Douglas Otis wrote to Michael Thomas:
Mailing lists removing _invalid_ signatures will not impact results
obtained with mailing-list permissive settings. Removing invalid
signatures better ensures evaluation of valid signatures.
If the list admin wishes to do any one of the many long time common
MLS features that essentially alters the originality of the new list
message, and it wishes to provide protocol consistency for the DKIM
domain, then it must consider the following:
1) As part of the list subscription verification process, the
MLS will verify that the subscribing domain is not restricted
via SSP by perform a simple lookup.
Expecting mailing-lists to accommodate DKIM policies is another way of
saying these services will be disrupted, as mailing-lists won't in
many cases.
1a) If the policy is STRICT, the subscription will be denied IFF
the list is not prepared to alter the integrity of the message.
It will behave as a simple passthru redistribution mailer.
That does not represent the operation or criteria used with the
typical mailing list.
Mike has suggested that by limiting the extent of DKIM signature
coverage, failure rates can be lowered to about 1 in 250, and this
appears to suggest specific message formats must be used.
With Mikes approach-
a) users receiving a DKIM verified messages are assured less
protection, and will be at greater risk of being deceived
b) when exploited, message filtering must then be used on the
unsigned portions of the message
c) higher level of legitimate messages will be in conflict with DKIM
policy assertions
1b) If the policy is ALL, then this allows the MLS to:
- leave the message alone if its not going to alter the
integrity of the message, or
- strip the original signature IFF it is prepared to
resign. Although DKIM-BASE has semantics to say only
one signature is required to be valid, this option
may help minimize downlink issues.
There might be some concerns regarding errors induced when handling
multiple signatures. Perhaps when the list is moderated, timeliness
may suffer. As much as possible, efforts needed to ensure signed
messages comply with a DKIM policy should be established by the domain
used in the From header.
1) Do not ask for additional receiver side processing of invalid
signatures.
2) Do not lower benefits obtained from processing DKIM signatures by
imposing partial coverage.
Give verifiers a good reason to process DKIM signatures!
1c) If the policy is UNKNOWN (optional), then this is where
the complexity might begin since the MLS can create
false positives. We might not even worry about DKIM
domains without SSP or those with direct DKIM=UNKNOWN
policy. Ignore them completely and let the download
handle it. But I can also see the logic to maybe:
- Leave the SIGNED message alone (valid/invalid) if its
not going to alter the integrity of the message, or
- Strip the VALID original signature IFF it is going to
alter the message and not resign.
A mailing list that applies SSP policy on incoming messages prior to
posting, removes full-coverage signatures prior to flatting and other
alterations, and then adds their full-coverage signature, safely
permits other domains to "authorize" its output. The means to
authorize mailing-list signatures can be accomplished with a single
TPA-SSP record with a scope of Sender, and not depend upon key
exchanges or domain delegations. While this will upset Mike, removing
original signatures eliminates a bad practice of extremely limited
signature coverage needed to survive list handling. It would also
encourage the use of TPA-SSP authorizations by those attempting to
impose either "all" or "strict" policies.
Overall, I think:
If the MLS sees the arrival of a new submission with a invalid
signature, I don't think the MLS should attempt to "promote" it to a
state where it could be viewed as an optional signing. If you strip
it, then you might do more harm than good here.
I am unsure what you mean by "promote".
When a mailing list applies DKIM policy to incoming messages,
including initially invalid signatures is likely to be misleading, and
a "proper" signature offers _no_ subsequent value when it is likely to
be damaged by list handling. A safe solution would be to remove
initial signatures. Uncertainty as to whether the removed signature
was ever valid should not matter. Only the signature added by the
list offers tangible benefit. Invalid signatures represent a waste of
resources and invite partial coverage signatures, which is a bad
practice from a security standpoint.
If the new list message arrives with a valid signature, then what
happens next depends on whether the MLS is altering the message, and/
or the DOMAIN has a SSP policy that is restrictive.
There might be a few such lists around. Should these be called
exploders? : )
if the new list message arrives with no signature, then depending on
the SSP, the MLS logic can be easily defined.
The whole point is that ideally, the MLS can be made to be protocol
consistent with DKIM/SSP.
Now is that feasible? It is asking too much of list servers?
Those (MLS people) who need it will do what it takes to make it
work. Others might not.
The burden should be placed on domains imposing restricted policies.
TPA-SSP is how this problem is best managed. The mailing-list
operators should be able to keep doing what they are doing, check for
policy compliance on incoming messages, and add their DKIM signature
to their output. Use of the From header can be accommodated when it
is authorized and signed by specific Sender headers for example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
