Patrick Ben Koetter <p@sys4.de>
2022-08-30
Abbreviation for DomainKeys Identified Mail (DKIM) Signatures
IETF Standard RFC 6376
A DNS-based mechanism to verify a senderdomain and message content
A sender-side email policy mechanism
A senderdomain uses DNS to publish cryptographic keys
The senderdomain uses the key(s) to create message checksums
The senderdomain notes the checksums as
DKIM-Signature in the message
A receiver identifies the DKIM-Signature
The receiver downloads the public cryptographic keys
The receiver verifies the checksums
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=switch.ch; l=6373; s=selector1; t=1661765855;
h=from:to:subject:date:message-id:mime-version;
bh=sPje1uXonypY4UtcpDas7jgSfAizdko8pfs71uKFpwo=;
b=iDuiuLdf3oWlwqlNM1OZ6wuByalbTra9nQJFgYqYCv/3DYjZd/4Q3FxW
YWa2O+gtsoFP45zFzWI0kMxjfptbTa0X6SKR9HDnoThIApErr5PmLktt5
6Vvi+VjMBOlVXD2mapr7PKXF06yX337w6k1z3y0z+OeBCK7cRkq2+7xiw
MjtCF8ILfffeNgwYijvkdnXGYfH/EPu11Nkcan1vuI5TD4Xt3aqpaTl1s
lX0SQXitWzl1aJOsyCYX3vPSjK3q+P7C7IEdkmw/IkuXNZljBwyFuQbbN
jihHY7htuyM6Z4q9X6vGGDY9jvCWMPoDb4SWAkfnTpfmFfrKxVN/CeGWn
Q==;
Signatures (may) break when message becomes altered, e.g.
Subject or mailing list
Br0ken MUAs may be abused to fool users
Original RFC does not specify algorithm change
Create a key-pair
Select a suitable selector
Publish the public key in DNS
Verify the public key
Configure DKIM signing software
Algorithm
Selector
Header-Signing-Policy
Oversigning
RSA and Ed25519
# dig +short TXT 20210728-rsa._domainkey.sys4.de.
"v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg \
QCy4L2R19HJeIPZO3XpP9Q/N9ArYY457Q03pF7IbLfs7p1SdgizBGCNeknc \
eET6IP3/6ZhqtTqz6G683N/HIVp2ot/K3vkcKzcITNTbb4479bk/qTKEDo9 \
YvI8zxFBOQ16yyHPa8DzMp79TFetGJGWzToNQE+RuHPCSbR3HEHCLcQIDAQ \
AB"
# dig +short TXT 20210728-ed25519._domainkey.sys4.de.
"v=DKIM1; k=ed25519; " "p=gouzcLASYvnaAKw3zyioMKYx144tmIpLX+K/hwd1Z5I="
Algorithm influences key length
Key length is key to speed
Prefer short keys with high security
Do not use RSA-SHA1! It has been deprecrated years ago.
Use RSA-SHA256 and Ed25519-SHA256
Selector is identical with left-most DNS label
The RR MUST be a TXT RR
The RR MUST locate in _domainkey.DOMAIN.TLD
Choose an incremental schema e.g. ymdM (Example:
22083001)
Indicate algo type in selector e.g. 22083001-rsa,
22083001-ed25519
You MUST sign From: and Subject: as
required by RFC
You SHOULD sign all headers of identity and security relevance
e.g. Sender:, Author:, Autocrypt:
as recommended
You MUST NOT sign any trace headers e.g.
Received:
Abusing inapt MUA implementations
Authentication-Results: mail.sys4.de;
dkim=pass header.d=switch.ch
header.s=selector1 header.b=LD+1SI0O;
dmarc=pass (policy=none) header.from=switch.ch;
spf=pass (mail.sys4.de: domain of
barbara.flaad@switch.ch designates
85.235.88.35 as permitted sender)
smtp.mailfrom=barbara.flaad@switch.ch
From: Barbara Flaad <barbara.flaad@switch.ch>
To: Patrick Ben Koetter <p@sys4.de>
Date: Fri, 19 Aug 2022 08:05:41 +0000
Subject: DNSSEC/DMARC Training in Lausanne
From: Hichael Mouseding <hichael.mouseding@switch.ch>
Enable oversigning
Sign N + 1 times even if N==0
Oversign MUST and SHOULD headers
Header and body signatures testify a moment in time when the message is fully compliant with your internal standards.
Sign at the very last moment just before you transfer the message!
Do not modify the message afterwards e.g. header whitewashing
Send (BCC) a copy of each message to your own (outbound) verifier and monitor your own production quality. Raise alarm when DKIM cannot be verified anymore.
DKIM allows to sign localpart@domainpart and / or
@domainpart
Both represent a distinct identity
Both will have their own reputation
Assess risks and use different keys for distinct risk groups
Remove RSA-SHA1 if you still use it
Use RSA-SHA256 and
Ed25519-SHA256
Check your DKIM signing software for Ed25519 support
DKIM uses crypto material. Rotate keys!
No standard for key usage time
Exploit risk is low
Damage is low to middle
Rotate every year
Reuse key for multiple domains (Hoster / Provider)