Re: [dmarc-ietf] Third party signatures

[Wei Chuang <[e-mail]>]

That's a good point around ARC as that's what it was meant to do.  And that got
me thinking that it might be helpful to systematically compare the
different proposed approaches and their pros and cons.  The next approach
would be to consider the general approach of the reversible transform idea
that several folks have proposed, and how that would look.  And that got me
rethinking the "DARA" work that we're already prototyping for DKIM replay
mitigation, if it can relate to mailing-list and forwarder modifications
and I now think DARA can help here too. The three different approaches have
distinct pros and cons.

The following is a summary of the comparison.  Attached is a more detailed
comparison as PDF that tries to work through what the algorithms would
likely do.
ARC
Use ARC to override the SPF and DKIM results at Receiver by those found at
the Forwarder.

Pros:

   -

   Uses existing SPF, DKIM and ARC standards.
   -

   Tolerates header and body modifications

Cons:


   -

   Receiver must trust the ARC headers generated by the forwarder.
   -

   Receiver must trust the modifications the forwarder made.
   -

   Receiver must trust that no ARC replay occurred


Transform

Proposed in draft-kucherawy-dkim-transform
<https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/02/> where
the forwarder can specify a "tf=" tag that specifies addition of Subject
header prefix, text footer to a mime-part, mimify plaintext, and adding a
mime-part representing a footer to an existing mime-tree to the
DKIM-Signature.  These all may be reversed to recover the original
signature.

DKIM-Signature: d=...; tf=subject,mime-wrap,

The ideas in draft-vesely-dmarc-mlm-transform-07
<https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform-07>
are conceptually similar though add support for ARC.

Pros:

   -

   Tolerates header and body modifications
   -

   Identifies the modifications
   -

   Does not require particular trust of the forwarder to be non-malicious

Cons:

   -

   Receiver must trust that no DKIM replay occurred
   -

   Might not compose across multiple modifying forwarders
   -

   Might not support all possible modifications by forwarder
   -

   Reversing all possible draft transformations is potentially complicated


DARAThis clarifies the DARA ideas in draft-chuang-replay-resistant-arc
<https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/> which
calls for authenticating a path from the Originator through the Forwarder
to the Receiver that's tolerant of modifications.  Some ideas of a
validated path are explored in draft-levine-dkim-conditional
<https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04>.

Pros:

   -

   Tolerates header and body modifications
   -

   Does not require particular trust of the forwarder to be non-malicious
   -

   Supports arbitrary many forwarders that may modify the message
   -

   Supports protocol unaware participants

Cons:

   -

   Requires DNS policy lookup on outbound delivery
   -

   Requires additional messages DKIM signing to support Bcc/Mailing-list
   recipients (each get their own signed copy)
   -

   Builds upon ARC which is considered complicated


-Wei


On Sat, May 6, 2023 at 7:42 AM John R Levine <[e-mail]> wrote:

> > It is not a commitment at this time.  That said, we are interested in
> > solving this problem and welcome collaboratively figuring out the right
> way
> > to do this.
>
> It seems to me that ARC provides the useful parts of third party
> signatures and, while rather complicated, has the benefit of actually
> existing.  The chain of authority runs from the relay host back to the
> original rather than the other way around, but that's a lot easier to do
> mechanically.
>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
>