On August 11, 2005 at 13:27, Jim Fenton wrote:
Why is it not safe? Because a malicious domain can send out messages
with forged rfc2822.From addresses where the domain portion does not
have any SSP defined. Therefore, when a DKIM verifier checks the
SSP for rfc2822.From, the message would not be considered suspicious
since no SSP record is available.
But how would they get a valid signature on behalf of the OA? Or are
you saying that one should treat the message differently from an
unsigned message because there is an invalid OA signature present?
There isn't any reason to apply a signature unless you know it will
verify correctly. Conversely, there isn't any reason to downgrade a
message simply because it has an invalid signature.
The way DKIM is defined, the signature is not bound to the
rfc2822.From. I.e. The i= tag can be anything. Therefore, any
domain can sign an outgoing message with any From: address in
the message header (something phishers will do).
To deal with this, DKIM supports SSPs, where the verifier checks
the SSP of the rfc2822.From to see what the signing policy is in
an attempt to prevent malicious domains using arbitrary rfc2822.From
addresses.
Now, according to the current SSP draft, if no SSP DNS record is
defined for rfc2822.From (or what the draft calls Originator
Address), the draft states the following:
If the Sender Signing Policy record does not exist, verifier systems
MUST assume that some messages from this entity are not signed and
the message SHOULD NOT be considered to be Suspicious.
Now, in this case, we have a signed message with no SSP defined.
Because of this, and past SSP discussion, appears the above statement
needs to be revised to avoid a security problem.
From a security perspective, if no DNS SSP record is defined, the safe
policy is to treat any _signed_ message as suspicious since it can
indicate malicious activity. Not doing so will lead to malicious
domains to adopt DKIM since during early stages of DKIM rollout,
many domains will not have SSP records defined.
There appears to be no real burden to require DNS SSP records to be
defined for entities that will have messages signed. For example,
if ISP example.com is to implement DKIM signing, along with defining
the appropriate DNS records for key data, it can easily define the
SSP records.
If example.com provides personal address services where users can
have addresses with their own domain (e.g. vanity domains, business
domains), then SSP records can be defined for the user's domain.
If example.com controls the nameservers for the domain, they can
define the SSPs directly. If not, then the domain owner must do it
if they want to support secure DKIM verification policies.
--ewh
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim