From: "Andrew Newton" <andy(_at_)hxr(_dot_)us>
Expressed as an exploit and stating how the
bad actors take advantage of this hole would
seem to be valuable, if not for the threats
analysis then for the security considerations.
I'll give it a first round to outline a DKIM Thread analysis:
Entry Points and Assets:
- Domain
- Private Key
- Private Key Password, if any
- MUA
- MSA
- MTA
- MDA
- MFA (Mail Filtering Agent)
- MLS (Mailing List Servers)
- MHS (Online Mail Hosting System)
Trusted Levels:
- Domain Owner
- DNS (Domain) Administrator
- System Operators (Sysops)
- Authorized user allowed to send routes
- Unauthorized user allowed to send local mail only
Protected Resources:
- Domain
- DNS
- Email Content
- MSA (submission machines)
- MDA (Final Storage)
- MUA (Reader/User)
Threats:
- Adversary gains unauthorized access to domain private key
- Internal thief (black market) of domain private key
- Adversary compromises MUA DKIM signers
- Adversary attack against non-DKIM community
- Invalid DKIM Spoofing
- Relaxed Policy DKIM Spoofing (High Threat)
- Adversary removal of signatures
- Adversary adds "This is a DKIM Safe Message" to body.
- New Social Engineering issues
- Adversary increases DKIM transaction frequency
- Adversary increases DKIM payload
- Adversary promotes BOUNCE attacks
- Adversary attacks known 3rd party servers
- Signers who do not honor OA SSP
- Agents modify email content
Its not just bad actors maliciously exploiting holes but holes due to legacy
operations just as well. Benign legacy software can easily create a threat
reaction at the downlinks (verifiers) and this includes non-DKIM supportive
systems taking action against or raising red-flags on unverified DKIM signed
messages.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim