LetzRelay blog

log

December 14, 2023


LetzRelay-MX experimenting "Declare All Recipients and Affirm (DARA)"
Overview of this new email security protocol


blog post 2023-12-14

Introduction

Our LetzRelay-MX email security MTA engine is currently experimenting with a new protocol that enhances the security of DKIM signatures – DARA – based on the IETF proposal by W. Chuang (Google) and B. Gonswana (Fastmail) called "Replay Resistant Authenticated Receiver Chain".

In the context of DKIM, existing email authentication techniques have known limitations. DKIM is vulnerable to replay attacks, as described by Google's W. Chuang in his IETF draft-ietf-dkim-replay-problem memo: "Spammers exploit a sender's account that supports signing with DKIM to capture an unwanted message with a valid DKIM signature. The spam is then distributed to many unsuspecting recipients. As ARC is based on the DKIM signature, ARC is de facto vulnerable to replay attacks."

This article aims at providing a technical overview on why-and-how DARA.

The underlying problem

The DomainKeys Identified Mail (DKIM, RFC6376) protocol cryptographically associates a domain name with a message's content, allowing detection of modifications during transit for the data covered by the cryptographic signature. In a replay attack, a recipient of a DKIM-signed message reposts the message to other recipients while retaining the original validation signature, thus exploiting the reputation of the original signer.

The goal of DARA

DARA aims to broadly address the following elements:

  • Any party can independently verify that a message followed the path intended by the original sender (initial sender), preventing DKIM and ARC replay attacks, as well as Shared Tenancy SPF attacks.
  • All recipients can determine if the message was altered during its journey and, if so, by whom.
  • Be able to tolerate non-participating parties, ensuring reasonable partial failure modes for non-participants, along with incentives to encourage their future participation.

Defining and propagating sender identity in the message flow

The protocol, as described in its current proposal, utilizes email authentication techniques such as ARC (Authenticated Received Chain) and DKIM (DomainKeys Identified Mail). In this protocol, tags and values are used to define sender-level parameters, with an optional usage feature. During message transmission, these tags and values are then used to declare parameters.

The protocol identifies and names Administrative Domains (ADMDs) based on the signer's domain. The message transfer path is defined as a sequence of these domains. ADMDs must identify themselves explicitly, and the "From" header domain must align with the initial ADMD domain, linking the "From" identity to the cryptographic signer.

Protocol security is ensured by signature and message verification between ADMDs to prevent malicious use of signature-related headers. The recipient must verify the message's integrity by examining the signatures. Verification failures are recorded and added. Even in the case of a failure reported by a previous recipient, the protocol encourages continuing generation and verification for evidence for future analysis.

In summary, the protocol uses ARC and DKIM for authentication, ensures alignment of the "From" header domain, addresses modifications by forwarders, and enforces signature and verification for each relay to ensure message integrity.

Declaring all recipients and affirm

The DARA protocol uses signed header validation compared to envelope headers. It has a lookup mechanism to support relays that are unaware of the protocol. Moreover, it publishes enough information for a third-party to independently validate results provided by the sender and recipient, such as:

  • Declaration of all recipients.
  • Awareness and support of the protocol.
  • Recipient verification.
  • Third-party verification.
  • Traceability of elements.

DARA as a DMARC authenticator

Assuming From alignment and chain construction with DARA, if the verification result is overall positive, it indicates DMARC authentication success. DARA and its overall verification result can provide a more resilient authentication against redirections and message body modifications than SPF or DKIM.

Regarding data privacy & security

DARA relies on declaring all recipients in mail headers, along with signing each of them. This could potentially disclose recipients in blind carbon copy (Bcc) or reveal all recipients in distribution lists. To avoid this, the message must be separately sent for each Bcc recipient or list member, where each recipient is then uniquely declared and signed.

From a security standpoint, caution should be exercised when selecting the sealing domain. DARA allows sharing a sealing domain among many different identities. However, senders doing so should be aware that recipient reputation systems may link to this shared sealing identity. Whenever possible, senders should match their sealing domain to their MX domain identity.

Conclusion

We are convinced that using the DARA protocol marks a significant advancement in enhancing the security of DKIM signatures. By addressing the well-documented vulnerabilities of DKIM, particularly in the face of DKIM replay attacks, the DARA protocol seems to stand as a robust and comprehensive solution.

By tackling the underlying issue of DKIM replay attacks, DARA strives to provide extensive protection, allowing all involved parties to independently verify the path of a message from the initial sender to the final recipient. The mechanisms for declaring recipients and assertion, coupled with the validation of signed headers against envelope headers, enhance traceability and message verification.

As a DMARC authenticator, DARA offers more resilient authentication against redirections and modifications to the message body than traditional methods such as SPF or DKIM. However, it is crucial to consider privacy-related aspects, ensuring that the declaration of recipients does not inadvertently lead to disclosure.

From a security perspective, the cautious use of the sealing domain is emphasized, highlighting the option for sharing while reminding senders to match their sealing domain with their MX domain identity.

By adopting the DARA protocol, stakeholders in the email security domain can bolster confidence in the path of messages, mitigate risks associated with DKIM signature exploitation, and provide stronger authentication in the complex and ever-evolving landscape of electronic communication.


Learn more on how LetzRelay-MX can help your organization be secured with Internet inbound emails.


Publication based on Replay Resistant Authenticated Receiver Chain IETF proposal.

© LetzRelay by AlSego.