From: "Andrew Newton" <[EMAIL PROTECTED]>
> 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
[email protected]
http://mipassoc.org/mailman/listinfo/ietf-dkim
