It is very clear from discussions on this list that the proposed DKIM2
standard is considered by many to be revolutionary, not evolutionary as
it should be. As a developer, I immediately identified areas which I
consider unworkable based on how I currently use and deploy DKIM1. These
changes give rise to concerns around e-mail reliability, the ability for
DKIM2 to succeed as a standard and critically, the ongoing ability to
cryptographically sign e-mails under varied use cases.
I am posting this so I can get some feedback on what has previously been
discussed and discounted, and hopefully gain insight into the direction
DKIM2 is heading, while also proposing what I consider to be a pragmatic
way forward. There is a lot of information in the mailing list archives,
however, I'm sure you'll all appreciate that it's not the easiest format
for someone, especially someone just discovering the DKIM2 proposal, to
navigate and interpret. I can, however, comment on the shortcomings I
can see in the proposed standard.
I see the proposed changes, for which there clearly are strong
proponents, as a step too far. It is my view that the objectives of
DKIM2 should be reined in, covering as many of the bases as possible,
but without significant changes to existing implementations, breaking
historic mail flow, or risking some users being unable to move beyond
DKIM1 due to technical requirements.
The main issue I see, as a sender, is the DKIM-replay mitigation. I
agree with making the t= tag a requirement. It's something I use in my
own implementation and I don't permit users to turn off. The proposed
rt= tag, however, necessitates a breaking change in e-mail flow as a
separate signed e-mail must be created for every BCC recipient, which
isn't always practical or desirable. This could lead to implementations
being stuck using DKIM1, which is fine so long as DKIM1 remains a first
class citizen. There is, however, no guarantee certain providers won't
at some point in the future make arbitrary decisions regarding its
acceptability, despite it remaining entirely fit for purpose.
I believe that the similar verification can be achieved through
non-breaking changes if the proposed ESMTP DKIM2 syntax is simply
extended to include a signed hash for each recipient. Any upstream
server supporting DKIM2 would pass this along to upstream servers and
the receiving server would be able to verify the recipient was an
intended recipient. This value would then be added to the e-mail prior
to delivery into the inbox, preserving the ability to perform
client-side verification. This doesn't fully address handover to
non-DKIM2 servers, but a simplified implementation would see faster
adoption of DKIM2 and realisation of the benefits sooner.
The hash would only need to include the e-mail address and original
DKIM-Selector header, signed using the same selector key as the header,
rather than being a component of the header itself. Such signing within
the constraints of RCPT TO is feasible if we take the opportunity to
phase out RSA signatures as we deploy DKIM2. The proposal already makes
Ed25519 a requirement for verifiers, so that isn't an unrealistic
stretch. I believe the barriers to an Ed25519 implementation have been
gone for some time. My own implementation was delayed while I waited for
LibreSSL to add support, but that development was completed more than
two years ago.
The RCPT TO approach would require very minor changes to filtering
protocols, allowing the extra parameters to be generated and observed by
filters. These enhancements would also bring potential benefits to other
filters through their being able to make use of parameters passed in
with RCPT TO. Importantly, it keeps much of the DKIM2-specific logic out
of the initial SMTP exchange, caters to all existing use cases, allows
flexibility of implementation and does not alter e-mail flow. Batched
deliveries for common recipients on a single server could proceed as
usual, with no special handling.
As current DKIM implementations vary in their placement of signatures
(even my own use varies depending if I am generating a signed e-mail or
simply signing), this should not be relied upon, with the proposed
sequence number (i=) for DKIM2 instead being used to determine which key
to apply (i=0) in the absence of a signature with a specific domain
match. If the first key fails, other intermediary keys that signed the
e-mail could be used to determine if a new RCPT TO signature is
acceptable, however, I consider the objective of supporting privacy
forwarding to be outside the scope of DKIM - DKIM is intended to ensure
e-mail integrity, and from the point of view of the sender, a forwarded
recipient is not where they sent the e-mail to.
As a side note, the 'correct' handling of forwarded e-mail in my view
should be to encapsulate the whole e-mail in a specifically designated
MIME container. From that point, it would be considered a completely
separate e-mail and verification would be based on the trust of the
forwarder, with the original e-mail remaining entirely intact for
subsequent verification. At the end of the day, the only question asked
by the receiver should be, "Do I trust the sender?"
The reason for the note above is because in my view the current proposal
looks at trust from completely the wrong perspective. Being able to
calculate changes and determine when those changes occurred is
effectively the opposite of what DKIM set out to do, which was to allow
the sender to claim ownership of messages and verify their authenticity.
Being able to determine who injected bad content is only useful if you
know the bad content is there. Trust is not knowing how an e-mail has
changed, it's about knowing if any changes were approved. The trust for
upstream modifications must therefore be at the direction of the sender,
not determined by the receiver, especially not if the changes are hidden
within the SMTP infrastructure itself. DKIM has been viewed and
implemented almost exclusively as if it were only a necessity for
delivery, despite its utility across the entire e-mail infrastructure. I
want to see that change and DKIM be brought to the foreground.
Despite the IETF mailing list itself clearly being antiquated, my view
is that mailing list issues are 20 years past being relevant. I
wholeheartedly agree with removal of the l= tag, which could be used to
accommodate minor additions that may be made by mailing list software,
but all modern mailing list software should be constructing and signing
a complete new e-mail and sending that to individual recipients. Current
industry guidelines for unsubscribe links etc., all suggest they should
be doing so, so let's not perpetuate the myth that mailing lists need
some sort of special treatment.
Editing based on policy is still relevant, as company policies still
often mandate the addition of disclaimers. Often, these are signed after
alterations are made, making changes a non-issue, but assuming they are
not, such changes, in my view, would be best served by establishing
explicit trust between the sender and upstream services.
This could be in the form of another header, giving explicit approval
for a named upstream domain to make changes and potentially limiting the
scope of these changes either to the immediate upstream domain or a
service trusted by them. If changes are made, the e-mail would be signed
again and starting with the original key, that and any subsequent keys
could be used to verify the server was permitted to make these changes
by verifying the chain of signed headers granting such permission and
testing the upstream signing policy at each step.
Granting change permissions would also mean intermediary services don't
need to be DKIM2 aware at all, allowing a smoother transition to the new
standard. These servers could even be DKIM1 hosts which routinely sign
and edit messages. Their changes would be trusted because the sender
said they can be. There are a large number of marketing services out
there which quite frankly shouldn't be holding the keys to their user's
domains. These services require control over keys for a domain because
they need to alter links and insert tracking etc., but would pass DKIM
checks using their own key if the ability to grant permission for
changes were to be added to the spec. Users would still need to setup a
DKIM key (which in most cases they would already have), but it would
remove the need for multiple CNAME records to be placed in DNS to
accommodate marketing providers and have the additional benefit of not
restricting those providers to switching between one or two
pre-determined selectors. This would greatly ease the ability to adopt
Ed25519 signatures ahead of a full DKIM1 to DKIM2 transition as it
wouldn't necessitate a hard switch over from one mechanism to another,
while at the same time improving security and allowing for longer
verification periods.
With regard to simplification, I suggest keeping the existing h=
arrangement and simply mandating additional headers. This is because
existing implementations must already calculate hashes in the order
presented and it creates an ambiguity for when over-signed headers
should be signed. The headers you most want to protect are also the ones
you probably want to over-sign, even if they are not meant to be
duplicated. While the proposed change would only represent a minor
change to code and should be easily implemented, other than reducing
header size by an insignificant amount, it otherwise appears to be
completely unnecessary. Likewise, I see no sense in hashing headers in
alphabetical order as it doesn't provide any protection against
reordering. It changes a critical step of verification, seemingly for
the sake of change. Keep the changes simple and a DKIM1 verifier would
still be able to verify a DKIM2 signature without any modifications, by
simply by ignoring unknown tags. What does the current RFC say about
unknown tags? Ignore them! Such compatibility also necessitates no
change to the existing canonicalisation default of simple/simple.
In summary, I see DKIM2 being v=2, with an updated list of required
headers, removal of the problematic l= tag, the removal of RSA and the
promotion of Ed25519, the ability to trust upstream domains and replay
protection provided by way of a signed DKIM2 hash added to RCPT TO and
compulsory t= tags.
Keep in mind this e-mail is largely a continuous stream of thoughts with
some minor edits, so I won't have covered every point and there will be
details that need more consideration, but I believe such an
implementation would be a solid upgrade to DKIM, worthy of the v=2
label, without introducing breaking changes.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
