Implement DKIM Risks #10

skomski · 2021-07-26T07:30:19Z

ImportantHeaderNotSigned (also mind quantity) (RFC6376) (1)
- rfc6376 recommends that all important header fields should be signed like for example subject, reply-to, date etc but only from: is required. In the wild various email providers sign much less than they should.
SDIDNotInFromHeader (RFC6376, DMARC Alignment Check)
- SDID means Signing Domain Identifier. DKIM signatures are checked against the SDID provided in the DKIM parameters. This SDID should be same as the Sender in Mail From: Header field but after the DKIM standard third-party signatures are allowed, but which in most cases are unwanted.
Check cryptographic key size
- under 2048 key length should be problematic
SignatureExpired
- DKIM signature timestamp is in the past
ValidatedWithoutDNSSEC
- validate DNS requests with DNSSEC
- support via libunbound or user configurable dns library

UsingSHA1 (RFC8301)
- old insecure hash algorithm
- deprecated and too insecure for a risk
UsingLengthField (RFC6376)
- email content only verified to a specific body length. Content after that open to manipulation.
- ignored in body hash calculation. Any manipulation results in an understandable error. As a risk not assessable for the end user
Multiple or none From: Fields (Forbidden by RFC5322, 1)
- forbidden by rfc5322
Ambiguous (complex) From: addresses and/or with mutiple domains (Forbidden by RFC7489 (DMARC)) (1)
- following DMARC because means less security problems down the line
- only one email address allowed in From: Header
Ambiguous domains: (ex.: NUL ambiguity and DNS) (1)
- https://en.wikipedia.org/wiki/IDN_homograph_attack
  - In the DKIMResult -> DKIMResult.extractedDomainFromSenderIdnaEncoded
  - DKIMVerifierTool shows the punycoded (idna) version
DuplicateImportantHeaderFields (ex.: two subjects;) (1)
handled as an error because independent of signatures and always suspicious for checked headers
maybe should be user configurable
problematic for user interface applications

Provide feedback