On Mon, 17 Oct 2005, Jim Fenton wrote:
This is a difficult question, because anything we do to accommodate
mailing lists introduces new vulnerabilities. Anything that
accommodates the addition of ads by mailing lists (since some are
advertising-supported) also accommodates the addition of undesirable
content to messages, unless you know exactly who the "good" mailing
lists are. Since new mailing lists are being created all the time,
it's very difficult to know which ones are "good", especially when
performing verification for an entire domain.
In this post I argue that adding "length" and using other means to
make sure signature can be verified after mail list not only does
not bring new threat to the system, but instead brings several new
options as to when email can be safely accepted.
-------------------
Lets assume that there is no "length" field in DKIM signature and
that all original sender email signatures would not survive mail
list except the ones coming through simple re-mailer. When recipient
received email and checks policy record, it'd do it by looking up
policy for domain listed in the "From" field. From there on it would
check for presence of signature with that email address (or domain)
1) If policy record says that no 3rd party signatures are allowed,
then since original invalid/non-verifiable signature is to be ignored,
it'd be the same as if no signature was present and email would have
to be considered to have been forged.
If 3rd-party signatures are allowed by policy record and mail list
does not add its own signature (which is going to be most for long
time), the same as above and email also has to be rejected.
[Both of the cases above would create serious problem for those
who want to try to use anti-spoofing policy records and would
mean it'd be close to impossible to use it at first or at all]
2) If 3rd-party signatures are allowed and mail list does add its own
signature, then email would be allowed through if it verifies. But the
threat in this case is that recipient can not really be certain that
address in From header field is not being forged/spoofed. Here all really
depends on the reputation of the mail list and if recipient knows knows
about this mail list.
In fact under above "3rd-party signature allowed" scenario its possible
for any 3rd party to just create new email with somebody else's "From"
address (even without original signature or with deliberately invalid
signature from some other email). So free for all spoofing assuming 3rd
party with good reputation is compromised.
So the result is that we can either have:
1. Policy with no 3rd-party signatures allowed and such users can not use
mail lists
2. Policy with 3rd-party signatures allowed and such emails can still
be spoofed (in this case if recipients see such emails or not,
depends on reputation of "3rd party" i.e. on some new service that
has not even been developed or tested).
-------------------
Now lets assume length is allowed - what changes? Well - the original
signature can potentially survive mail list and be verifiable. There
are several scenarios to be looked at:
2.B) The original email changed enough that original signature can not
be veriried, but amail list adds its own one. This is scenario 2 above.
3) The original signature does survive and is verifiable (accounting for
length) and mail list also adds its own one. I would argue that is also
practically the same as scenario 2 above because if recipient sees such
email or not depends on reputation of 3rd-party re-mailer as with 2.
But this slightly more advantageous because original signature can still
be verified and tells which part of email is good - this gives recipient
possibility that in case re-mailer has no or unknown reputation, it can
decide to "cut" the newly added portion of email and let the rest through.
Note: In my view in case of multiple signatures and length data, who to
consider to provide responsible party information (for reputation
check) would be the first signature which has the same length listed
as body of email data, i.e. if remailer did not add any new data
then the original sender's signature would provide responsible party
info, but if mail list does add its own data, then its signature
provides responsible party.
4) Mail list does not add new signature but original signature can still
be verified (cases of mail lists with software not yet capable of adding
signatures). In this case if it were that no length data were present than
email check would cause a rejection and it is covered under #1 above.
But here there possibility to actually let email through. The recipient
can find that length of the email is different and then would know that
email came through 3rd party (that did not add signature, otherwise see 3)
and then it maybe able to use some other way to find reputation of the
sending party - perhaps mail list had SPF record and that data and MAILFROM
identity (admittedly not quite the same) can then be used for reputation
check. If reputation of this mail list is good, then mail can be let
through and it would again be the same as scenario 2.
If no reputation check is possible, the recipient just like in 3 can
still decide to cut down email to known good part and let this through.
5) When user has no 3rd-party signatures allowed in policy record and
recipient see that such email is different length (i.e. it came through
3rd party), I would argue that recipient can then reject such emails
(that is what policy says after all!) but optionally it can also still
decide to cut email to exactly what it originally was and let it through.
-------------------
So as you can see adding length and trying to create such signature
that could be verified after mail list actually does not add a new
threat to the system as it all comes down to the same threat present
by allowing 3rd party signatures in the first place and doing this is
necessary if you want to allow those users who want anti-spoofing
protection to participate in mail lists.
On the other hand with length and other ways to make sure original
signature can be verified after going through mail list, we have
several new options that would allow delivery of email to end users
(different type of reputation check with non-signature adding lists
or cutting out newly added mail list content) rather then outright
rejection.
There are ONLY benefits with trying to make sure signature can be
verified after mail list processing!
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
ietf-dkim mailing list
http://dkim.org