-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Internet-Draft draft-ietf-dkim-dkim2-spec-09.txt is now available. It is a
>work item of the Domain Keys Identified Mail (DKIM) WG of the IETF.
>
> Title: DomainKeys Identified Mail Signatures v2 (DKIM2)
> Authors: Richard Clayton
> Wei Chuang
> Bron Gondwana
> Name: draft-ietf-dkim-dkim2-spec-09.txt
> Pages: 68
> Dates: 2026-11-01
This is pretty much identical to -08
* Removed key length MUST from Verifiers
Verifiers give results; they don't have MUST strictures
* Ensured all Verification checks have error text suggestions
So there's a few more error messages to consider
* Clarified that there is only one key record allowed per selector
DKIM1 says this was undefined, DKIM2 firmly says it is an error
* Verifiers may regard algorithms and key lengths as insecure
Which they would do eventually even without text about it
* No DKIM2 header fields at all is now NONE rather than PERMERROR
This matches Bron's Authentication-Results spec
--------------------------------
AND: THIS DOES AFFECT IMPLEMENTATIONS
--------------------------------
When we introduced the requirement for From header fields to be
Authentic (which is true for all legitimate mail) we did not
realise quite how many ESPs had been delegated a subdomain
of "example.com" and were signing
From: <[email protected]>
DKIM-Signature: d=esp.example.com ...
viz using the subdomain as the Signing Domain.
Since DKIM2 has a consistent rule that says that a signing domain is
only allowed to sign things (there are 4 places we use a "relaxed domain
match") at its own level or below this just does not work in DKIM2. You
don't get a "Fully Verified DKIM2 Message" as a Verifier result.
DMARC dealt with this by means of "strict/relaxed" alignment and (rather
holding our noses) we have now done something similar in the DKIM2 spec.
We looked at real data from $DAYJOB$ and use of subdomains is really
rather widespread and it has always been a design aim of DKIM2 that
customers of ESPs do not have to update their DNS to use DKIM2 (because
DNS updating is much harder than it has any right to be in 2026).
Anyway ... the spec now says that when deciding if a From header field
is Authentic (the other 3 uses of relaxed domain match are unaffected)
the matching algorithm in run in both directions, both "up" and "down".
Hence using a subdomain as the Signing Domain now works OK.
Of course in some cases this is Not A Good Idea At All. Consider ga.gov
that delegates primaryschool.ga.gov -- if the primary school is
compromised and their private keys stolen then the thieves can sign a
message with
"From: <[email protected]>"
and it will be believed to be Authentic.
So we have added a "Domain Policy Record" which contains at "strict"
flag which says that subdomains cannot authenticate their parents. We
have put this flag at _domainkeys.example.com (i.e. above the selectors
at the location that the original DomainKeys scheme (pre-DKIM1) used. We
have of course ensured that ancient DomainKeys records don't interfere.
So _domainkeys.ga.gov adds a record "v=DKIM1; f=strict;" and the thieves
will be frustrated.
We are holding our noses, BTW, because people who want subdomains to be
restricted have to act to add a new record -- we generally like security
controls to fail closed, but in this case this is incompatible with the
design aim of having existing DKIM1 keys continue to work.
Enjoy !
BTW: there is a new "-dkim2-dns" draft coming RSN which will cover
things that are not in -dkim2-spec-09".
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaufzMWHfC/FfW545EQLDdACgrku6eB+2reV/E//YaGf3U3/nltAAoKds
ECpn1XA6HmtlzY9nVWx4nyW8
=dflV
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
