Opened 2 years ago

Last modified 22 months ago

#100 assigned defect

A-R Security concerns and their impact on ARC

Reported by: dougfoster.emailstandards@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #2 (DMARC improvements to better support indirect email flows)
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

Within the Authentication-Results (A-R) specification, the authserv-id acts as an authentication mechanism between the server which creates the header record and the server which utilizes it. Unlike most authentication systems, it has no secret element. This creates some risks that need to be mitigated.

These are three general risk mitigation strategies for this problem.

  • Prevent the authentication information from being known to unauthorized entities.
  • Block unauthorized entities from being able to use the authentication information even if they learn it.
  • Limit the consequences of a breach if unauthorized persons are able to use the authentication information.

Let's consider how each relates to A-R

Restricting Knowledge
Since the authserv-id is inserted into every message, it is available to any recipient or intermediate MTA that chooses to inspect the header data. At minimum, this includes every recipient within the domain. If any forwarding occurs to other domains, the information is available to those recipients as well, unless it is stripped. Some existing mailbox providers are known to leave internal A-R records in place on outgoing messages and to leave external A-R records in place on incoming messages. In general, we can conclude that secrecy of cleartext authserv-ids is not feasible.

Restricting Use
Misuse of A-R data can be prevented if spoofed A-R content is filtered before it is seen by a utilizing server. It is likely that existing implementations filter incoming A-R data which includes internal authserv-ids, but this cannot be known without mounting an actual attack. We can say at minimum that conditional filtering is riskier than unconditional filtering, since it assumes that the filter and the utiltizing server will always have synchronized configurations. However, spoofed A-R data could also be included within a message submitted internally from a client MUA, so filtering would need to occur at both the border MTAs and submission-accepting MTAs. In some cases, the submission-accepting MTA may be the utilizing mailstore. In general, we can conclude that spoof prevention is a difficult technical challenge.

Restricting Usefulness
The usefulness of an A-R spoofing attack will depend on how A-R is used. As long as it is used to communicate information from a filtering MTA to a non-filtering MTA, the utility of the informaton is limited and consequently the value of a spoofing attack is fairly limited. In short, the A-R data is not likely to be spoofed because a successful spoof is not likely to be beneficial to the attacker.

However, when A-R headers are used to generate ARC sets, spoofed A-R data becomes more useful to the attacker. Spoofed A-R data can be used to construct an incorrect ARC set. That ARC set may be used by a subsequent ADMD which trusts the signing domain. The weaknesses within A-R become weaknesses in ARC. ARC already has difficult trust issues to overcome, and A-R weakness aggravates those difficulties.

Ticket 95 contains my proposal for relieving ARC of its current dependency on A-R. This is supporting documention.

Change History (3)

comment:1 Changed 2 years ago by dougfoster.emailstandards@…

  • Milestone set to Deliverable #2 (DMARC improvements to better support indirect email flows)
  • Priority changed from minor to major

comment:2 Changed 22 months ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from new to accepted

comment:3 Changed 22 months ago by todd.herr@…

  • Status changed from accepted to assigned
Note: See TracTickets for help on using tickets.