To avoid a lengthy e-mail, I have split my concerns regarding
draft-gondwana-dkim2-header-x into two e-mails focusing on specific
design issues.
Herein, I discuss the proposed RCPT TO and MAIL FROM signing techniques
and suggest alternative approaches that, to the maximum extent possible,
preserve the linear flow and objectives of DKIM1, without compromising
the objectives of DKIM2.
I am happy to write up a more formal description if requested.
== RCPT TO Signing: Enhanced Compatibility and Privacy
I have previously discussed the issues with including rt= in the
signature and the inability to use DKIM2 in certain valid use cases.
Some comments regarding this shortcoming have been outright dismissive,
which is troubling given DKIM2's objective of superseding DKIM1 and the
likelihood that receivers will eventually demand DKIM2 be used.
I outlined a simple solution to this issue in an earlier e-mail, so I
won't go into details again here unless clarification is requested,
however, in summary, my proposal is to move the rt= details out of the
header and into the envelope by adding a signed value to RCPT TO as part
of the proposed DKIM2 ESMTP extension. Hashing could also be used to
retain RSA compatibility. This information would be inserted into the
e-mail at an appropriate juncture, preserving end-to-end verification.
The only technical limitation to overcome is filters would need to be
able to update RCPT TO. Both milter and OpenSMTPD filters already
support negotiating capabilities, so this would be minimally invasive
and insignificant compared to the extensive rework required to implement
other aspects of the proposal as it currently stands.
As the signed hash would be comprised of the added RCPT TO information
and the original DKIM2-Signature rather than being integral to the
signature itself, this approach retains the linear signing flow of DKIM1
and is compatible with existing crypto libraries. Copying hash state is
not supported by all libraries and hardware implementations may store
hash state internally, so even when multiple active headers are
permitted, there is limited potential for optimisation under the current
proposal.
By shifting to RCPT TO, there are several practical advantages over the
current rt= header approach:
* Ensures no leakage of BCC information even if filters or SMTP hosts
are misconfigured.
* Eliminates the requirement to split messages at the earliest
opportunity as splitting would only required on handover to systems not
advertising DKIM2 support.
* Simpler to implement and optimise.
* Preserves existing DKIM1 use cases where the original signer may not
be able to split e-mails.
== MAIL FROM: Eliminating pp=/nd= and Preserving Bounce Integrity
DKIM2 proposes changing MAIL FROM between hops. Once again, this
represents a significant change in mail flow and appears completely
unnecessary to achieve all but one of the stated objectives, which
itself represents a minor edge case.
The original MAIL FROM should be preserved and bounce notifications
should be sent directly to any domain that requests them via their
DKIM2-Signature. Sending messages back up the chain only introduces
multiple points of failure and prevents the necessary information
getting back to those who depend on them for general housekeeping.
As is the case now, a receiver may choose not to send notices regarding
specific states to systems that don't need to see them. For example, it
is useful for upstream services to know when they are forwarding
reported spam, but they don't need to know a specific account is
invalid. The sender of bounces will, however, be able to ensure any
messages they do send are not misdirected to innocent parties by
verifying the chain of custody.
The DKIM2-Signature flags could also be extended to allow relays to
request specific types of notifications. That's a potential enhancement
I think is worthy of further discussion.
Sending bounces to all verified parties that request them would
partially mitigate the problem of ESPs changing MAIL FROM as a means to
track bounces. Their doing so precludes the use of VERP to track
failures or for other purposes by the original sender and has the
unfortunate side effect of keeping bad addresses in mailing lists unless
removed through the proprietary mechanisms ESPs may provide. ESPs would
also benefit from simplified customer setup.
RFC5321 requires MAIL FROM to be rewritten for on-sending to an alias or
list. Correctly implemented, there should be no backscatter to the
original MAIL FROM address. The argument for improved privacy forwarders
is therefore only in support of a minor edge case that exists due to
non-compliance with RFC5321.
Notwithstanding the above, preventing information regarding failures
being sent to the originator in the case of mailing lists or forwarding
can be achieved by limiting the scope of any feedback to the last
service which added an "exploded" tag in its DKIM2-Signature (consider
adding a "forwarded" flag?).
A DKIM2-capable server receiving bounces would first confirm the
legitimacy of a bounce to the best of its ability (without defining the
feedback mechanism, the chain of custody cannot be verified
cryptographically), before applying policies determining if it should be
passed to administrators or clients, or be used to perform automated tasks.
There has already been some discussion about removing pp= and nd=. Both
of these are problematic because they leak information about how e-mail
is handled for a domain. They may also require additional DNS queries
for domain, MX or a new _pp TXT record, all of which introduce further
potential points of failure. There is still a need to sign the chain of
custody however.
Rather than rewriting MAIL FROM between hops, I propose using the DKIM2
ESMTP extension to transmit a lightweight authorisation signature. This
signature would cover the most recent DKIM2-Signature and the domain
expected to sign at the next hop. The domain should be derived from the
A/AAAA record of the host. The receiver, being any relay or MX, would
only be required to have keys for domains referring to them in published
A/AAAA records, not keys for each domain it handles mail for.
In order to verify the chain of custody and avoid editing the e-mail
each time an attempt is made to send it, the signed value would be added
to the headers by the DKIM2 filter on the receiving server, which is
already privy to MAIL FROM information. This could be inserted directly
into the next DKIM2-Signature generated by that host, resulting in
bi-directional signing of the chain of custody without adding additional
headers. No or minimal changes to filter capabilities would be needed in
order to support this. Having the receiver add the information to the
headers rather than the sender allows the signature to be added after
decisions regarding routing are made (potentially days after the DKIM2
signature is generated) and limits the scope of changes required to
implement the DKIM2 ESMTP extension.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
