Re: [dmarc-ietf] Third party signatures

[Douglas Foster <[e-mail]>]

Hector, my life is short, and this group already takes up more of it than
my wife wants.   If you are a subject matter expert on all of those RFCs,
we need you to summarize the relevant pieces for those of us who are not.

But you imply that if I read all of those RFCs, I would see that your
third-party authentication proposal is the solution.    I don't see that
happening, and I am looking for you to adapt your pitch in the light of the
pushback that has been given already.   To recapitulate one aspect:

Today, mailing lists ask this:
"Subscriber evaluators need to trust any From address for messages that are
verifiably from the List Server's MailFrom address."

Third-party authentication with DNS entries asks this:

   - The subscriber asks his admin to publish trust for the list server
   domain to impersonate the subscriber domain, without limit.
   - The domain admin publishes the trust indicator
   - The evaluators (which are usually the same domain admins) also choose
   to accept the trust indicators from other domains.

The first step requires communication flows that may not happen.   The
second and third steps require grants of trust that are not easily
obtained.   If the process breaks down for any one subscriber, the
necessary exception mechanism for every evaluator is:

"Subscriber evaluators need to trust any From address for messages that are
verifiably from the List Server's MailFrom address."

Of the proposals on the table, Murray's has the advantage because hashing
solves the scaling problem.   But even Murray has lost hope of it being
accepted.

As for ARC, please take a look at the forwarding section of my Best
Practices draft.  I lay out the reasons why evaluators need to know whether
a message was forwarded or not, and suggest a half dozen or so clues for
detecting a forward.   It is pretty obvious that ARC is the most useful
entry in the list.   By providing data that helps support the mailing list
trust request, it moves the needle forward in a way that third-party
authentication does not.   ARC also provides value for forwarding
situations other than mailing lists.

Doug Foster

On Mon, May 15, 2023 at 10:32 PM Hector Santos <hsantos=
[e-mail]> wrote:

> Wei,
>
> Have you studied the past R&D and functional specifications, architectural
> surrounding SPF and DKIM leading up to DMARC?
>
>    RFC5598  Internet Mail Architecture
>    RFC5322  Internet Message Format
>    RFC5321  Simple Mail Transfer Protocol
>    RFC4405  SUBMITTER SMTP Service Extension
>    RFC4406  Sender ID: Authenticating E-Mail
>    RFC4407  Purported Responsible Address (PRA)
>    RFC4408  Sender Policy Framework (SPF)
>    RFC4686  Analysis of Threats Motivating DKIM
>    RFC4870  DomainKeys
>    RFC4871  DKIM (RFC5672.TXT,  RFC6376.TXT)
>    RFC5016  Requirements for a DKIM Signing Practices Protocol
>    RFC5451  Message Header Field for Indicating Message Authentication
> Status
>    RFC5518  Vouch By Reference
>    RFC5585  DKIM Service Overview
>    RFC5617  DKIM Author Domain Signing Practices (ADSP)
>    RFC5863  DKIM Development, Deployment, and Operations
>    RFC5965  An Extensible Format for Email Feedback Reports
>    RFC6376  DomainKeys Identified Mail (DKIM) Signatures
>    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
>    RFC6541  DomainKeys Identified Mail (DKIM) Authorized Third-Party
> Signatures
>
> I find it technically unfeasible and non-logical to support a high
> overhead, complex ARC concept that has no promise of any solution for a
> DKIM Policy model we have been seeking since 2005.
>
> What are we solving in the first place with ARC?  The ability to revert to
> original integrity due to unknown middle wares changes?  What ever happen
> to passthru mail transports?
>
> In my technical view, it has been the PORT 25 unsolicited 3rd party
> signature unauthorized by the author domain due to the dearth of scaled
> AUTHOR::SIGNER Authorization methods.   ARC is not resolving this problem.
> The overhead is horrendous.
>
> We have been seeking deterministic protocols to filter out failures with
> zero to low false positive.  Diffusion by Osmosis!
> We don't have it today.   It has been made more complex than it really
> is.   I recommend to study the past work.
>
> Thank you.
>
> --
> Hector Santos, CEO/CTO
> Santronics Software, Inc.
>
>
>
>
> On 5/15/2023 5:02 AM, Wei Chuang wrote:
>
> 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
>
>
> DARA This 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.
>>
>
>
> _______________________________________________
> dmarc mailing [e-mail]://www.ietf.org/mailman/listinfo/dmarc
>
>
>
> --
> Hector Santos,https://santronics.comhttps://winserver.com
>
>  _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>