On Oct 19, 2005, at 7:21 AM, Barry Leiba wrote:
Douglas Otis wrote:
When the From/Sender headers do not represent the actual sender,
such messages may be forfeit had the domain contained within the
From/Sender published close-ended authorizations. SSP policies
reduce delivery integrity for other senders! : (
I don't agree. I believe the combination of the ability to specify
which header you're attesting to, combined with the ability to specify
in the SSP whether you sign and whether you authorize third parties
to sign (though I'm not happy with the confusion that the term "third
party" has generated, I don't have a better term in mind), gives the
flexibility we need to solve the problem we're trying to solve --
which, keep in mind, is a limited one.
Signing messages from your domain that adhere to RFC-2822 may be
using Resent-Sender, Resent-From, or Sender headers, rather than the
From to convey the actual sender. (This also ignores possible
exploits using Reply-To and MAILFROM.) For SSP, the choice of third-
party authorization is _not_ within within the sending domain's
control. There is _nothing_ that can be done to ensure delivery of
the valid message without changing the message encapsulation. : (
This breaks email and will cause expensive support issues. SSP
expects the entire email infrastructure to change. Path registration
would be equally onerous. However, DKIM can enable new friendly
modes of recipient protection that can be applied, to a limited
extent at the MTA, and a much greater extent at the MUA. There is a
much more powerful, yet cheaper and friendlier alternative methods
for DKIM to offer general protections without a large loss in the
delivery integrity created by RFC-2822 incompatibility.
Allow the MUA or MTA, with the guidance of binding recommendations
carried securely within the message itself, to opportunistically
associate the email-address with the signing-domain. This type of
binding would be an effective means to offer protection at the pretty
name _and_ the email address. Nothing has to be visible for there be
increased protections offered when using this approach. Much of the
spoofing would be prevented in this manner for _any_ prior
correspondence and not require any policy assertions whatsoever nor
risk a sizable reduction in email's delivery integrity.
This opportunistic approach can be improved by specifying the role of
the signer, such as:
- Originating
- Resending
- Verifying
Even Intra-domain spoofing could be detected by adding opaque-
identifiers that also combat abusive replays and isolate compromised
systems. A signature may be repeated at high frequencies for
legitimate reasons. I have been told Yahoo has mailing lists that
approach a million subscribers, where a list server could be one such
example of a legitimate replay of signed messages.
There could be a practice that nulls signatures for Originating or
Resending signatures when the Verifying signature is added. A
Verifying signature could not be used to send a message, where the
nullification of these other signatures after verification would
reduce the opportunity for messages to be used to stage a replay.
The opaque-identifier strategy would also highlight the replay
sources when an attack is in progress. There could be lists quickly
created that indicate domains that do not protect signatures and
domains that allow replay attacks. : )
protection and makes the domain highly restricted to two-party
use, but still suitable for sensitive transactions.
- All originating headers match the signing-domain!
I argue that "sensitive transactions" are not what DKIM is about. If
one wants to protect sensitive transactions, one should use S/MIME or
OpenPGP.
From what I understand, Banks find S/MIME makes their messages
appear to be spoofs. S/MIME at this time will not work for a few
large ISPs like AOL. DKIM could be installed at the gateway where
the ISP's standard techniques could be applied to indicate the level
of verification achieved. DKIM does not change the appearance of the
message, although at this point, should it really matter. Phishers
have become rather proficient copying the look and feel.
That said, I wouldn't object to an additional, strict signing policy
that lists headers and asserts that they must match. I think it'd be
rather nice to say, "Only consider a message validly signed by us if
the signature verifies AND ALL of the following SMTP and header fields
represent our domain: HELO, MAIL-FROM, From, Sender, Reply-To [...]."
What do others think of this?
I see this would be beneficial in a few cases. I also don't see the
logic for limiting policy assertions to "Only we are allowed to use
the From header unless this has multiple addresses, in which case
only we can use the Sender header" policy statement. The havoc from
such a policy restriction would have already been created. Any
domain that makes this policy statement would then be radio-active
with respect to delivery integrity for multiple party communications,
and thus should be used in exigent cases that are limited to two-
party communications.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org