[dmarc-ietf] Weakend Signatures vs Experimental draft

["Douglas E. Foster" <[e-mail]>]

Weakened signatures seem capable of getting to the desired goal more quickly than the draft under consideration.

Building on prior discussions of conditional signatures, I define a "weakened signature" as:
one where SUBJECT is omitted from the header list, and l=0 is included to exclude the body content.   The protected user-visible content becomes limited to From, To, and Date headers.

Benefits
======

Legitimate edits are allowed.
Mailing lists, auto-forwarders, and other mediators can edit subject and body content without invalidating the signature.
DMARC policy can still be set to p=reject or p=quarantine.

Only Mediators can use the weakened signature
To benefit from the weakened signature, a system must be in possession of a validly-signed message.

Time-Limited
A weak signature is only valid until is expiration time.

No specification needed
This approach can be implemented immediately, by anyone.

Disadvantages
============

Replay Attacks are possible.
Any attacker who gains possession of a weakened-signature message can use it to send an unlimited number of messages, using the same From/To/Date combination, until the signature expiration.   Since the SMTP Recipient address is not required to align with the Message To header, the attacks could include recipients unrelated to the original message.

Potentially-wide scope:
Every recipient of a mailing list message is a potential source for leakage of signature information, so the message is at risk both when in transit and when at rest in destination systems.

Mitigation Options
==============

Sender-side mitigations by the Domain Owner

Limited Deployment
A sender could choose to only apply the weakened signature when the destination is a known to need to make changes and is trusted to do so.   This limits the opportunity for messages to be intercepted for use in a replay attack.

Dual Signatures
A sender could apply a weakened signature and a traditional signature, to permit recipient systems to evaluate messages based on the strength of the signature used.   By using different selectors for the two signatures, DMARC reporting would help identify which mediators are making signature-altering changes.  To help ensure that a traditional signature is detected and used first by the receiving system, the traditional signature should appear first, followed by the weakened one.

Recipient-side mitigations

A recipient could check signature parameters to determine whether it was weakened or traditional, and prefer the traditional signature when both are valid.    When only a weakened signature is valid, the recipient can perform differential handling, based on the reputation of the submitting server and other factors.

Changes required:
==============

Sending Domains
Senders would need to choose to participate in this scheme by applying a weakened signature.
Conditional use of a weakened signature may require software changes.
Simultaneous application of weakened and traditional signatures may require software changes.

Mediators
Mediators would need to test for the presence of a weakened signature, and use that result to decide whether From-rewrite could be avoided.

Recipient Domains
Recipients can be assumed to participate immediately, on the assumption that very few recipients currently apply differential handling of traditional and weakened.
Software changes may be needed, if recipient domains wish to implement differential handling of traditional and weakened signature.

Comparison to Crocker Draft
======================
Draft proposal requires sender domains to opt-in by configuring a DNS entry, so all outbound messages are affected.
Draft proposal allows impersonation by any system which can apply a Sender header and a valid signature for the sender domain, so the range of possible spoof sources is unlimited once a domain opts-in.
Draft proposal can be used to impersonate without intercepting a valid message.
Draft proposal requires recipient domains to opt-in, and to implement new logic when doing so.
Draft proposal does not provide a way for mailing lists to know or assume that the recipient domain is participating.