Re: [dmarc-ietf] Third party signatures

[Douglas Foster]

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  wrote:

> Wei,
>
> Have you studied the past R 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 

Re: [dmarc-ietf] Third party signatures

[Alessandro Vesely]

On Tue 16/May/2023 04:32:21 +0200 Hector Santos wrote:
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.



The concept evolved from the need to export Authentication-Results:.  The 
outcome is just a little more complex than DKIM.  Technical feasibility is 
proven by implementations.  I, for one, implemented it on top of DKIM without 
having to go through hoops.




What are we solving in the first place with ARC?



IMHO, besides collecting A-Rs at various steps, ARC brings the ability to 
gather a chain of authentications.  Compared to an unordered set of DKIM 
signatures, ARC delivers a neat verification already at the (low) algorithmic 
level.


You have to implement it to appreciate it fully.


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.



Like DKIM, ARC tells you nothing if you don't trust the signers.


Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Hector Santos]

Wei,

Have you studied the past R 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 
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 
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 
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 
. 



Pros:

 *

Tolerates header and body modifications

 *

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

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

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
 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

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
 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
.

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  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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
>


Mailing-List Authentication Comparison (ietf-dkim).pdf
Description: Adobe PDF document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[John R Levine]

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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

On Tue, May 2, 2023 at 10:21 AM Murray S. Kucherawy 
wrote:

> On Tue, May 2, 2023 at 10:06 AM John Levine  wrote:
>
>> No large provider has ever expressed any interest in either so I cannot
>> see any reason to spend more time on either one.
>>
>
> I believe Wei has expressed interest in the transforms stuff, but I don't
> recall whether that was a commitment to implement and experiment.  I know
> how engineers at big companies are.  :-)
>

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.
-Wei


>
> -MSK, participating
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Alessandro Vesely]

On Tue 02/May/2023 19:21:13 +0200 Murray S. Kucherawy wrote:

On Tue, May 2, 2023 at 10:06 AM John Levine  wrote:

No large provider has ever expressed any interest in either so I cannot 
see any reason to spend more time on either one.


I believe Wei has expressed interest in the transforms stuff, but I don't 
recall whether that was a commitment to implement and experiment.  I know 
how engineers at big companies are.  :-)



I released experimental undoing of DKIM transformation on 28 November 2020. 
 Albeit zdkimfilter works on Courier, it  can be installed without it with 
a bit of tweaking, and run offline.  I commented recently on how it works.


Wei said it belongs to the DKIM WG.  Its impact on DMARC is limited to use 
it as a tool for monitoring MLM agreements, methinks.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Murray S. Kucherawy]

On Tue, May 2, 2023 at 10:06 AM John Levine  wrote:

> No large provider has ever expressed any interest in either so I cannot
> see any reason to spend more time on either one.
>

I believe Wei has expressed interest in the transforms stuff, but I don't
recall whether that was a commitment to implement and experiment.  I know
how engineers at big companies are.  :-)

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[John Levine]

It appears that Murray S. Kucherawy   said:
>And I think the conditional signatures ideas suffer from the same two
>issues I identified above.

It's not quite as bad because with conditional signatures you can
decide for each message if any third party signatures are OK. That
mostly solves the security problem, since you're only saying that the
third party can sign messages that look more or less like this one,
but I agree the scale problem is roughly the same. It'd be a
signficant amount of work to adjust outgoing mail servers to decide if
and when to apply conditional signatures.

No large provider has ever expressed any interest in either so I cannot
see any reason to spend more time on either one.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Third party signatures

[Wei Chuang]

On Mon, May 1, 2023 at 8:23 PM Murray S. Kucherawy 
wrote:

> Some thoughts about the third party signature discussion that happened
> over the last couple of weeks while I was away:
>
> I wrote ATPS as an experiment in 2012.  At the time we were still
> finishing DKIM (RFC 6376 was only five months earlier), and still talking
> about whether a third party signing solution was even possible.  Doug Otis
> had a similar "TPA" draft out at the time, but neither of us were getting
> any traction from the working group.  The community was quite dubious that
> the general idea could work, and TPA had a lot of complexity to it that I
> thought we could do without (or, at least, if we did need it, we could add
> it in later).  Since I had an open source platform to play with, I decided
> to implement something, include it in the platform, ship it, and see what
> happens.  I managed to get an AD to sponsor what became RFC 6541 to
> encourage other implementations to try it.
>
> In the years that followed, I think I only ever saw one consumer of that
> platform, other than me, enable the ATPS feature and try it out.  I know of
> only Hector's code as another implementation.  There have been claims that
> it was not "marketed" well, but I never saw any of this as something in
> need of marketing.  If it's a feature people needed, they would ask for it
> and turn it on, and we would hear that it solved a problem.  It wasn't hard
> to configure.  To me, that doesn't say we did a poor job of "marketing" it,
> but more that a path to its success wasn't clear in the contexts where we
> really needed it.
>
> There are two main reasons I can see for this, as both an implementer and
> a consumer of this stuff, when it comes to mailing lists and the DMARC
> problem:
>
> (1) Scale.  For mailing lists, ATPS only works if you list in your DNS all
> other domains that run lists to which your users subscribe.  If you have a
> handful of users, you might be able to work this out.  If you have a GMail
> number of users, you now have giant problems of user support and keeping
> that list current: "You mean I have to register every domain where I join a
> list?  This sucks!"  "I forgot to de-register a domain years ago, sorry.
> (And now that domain is still an authorized third party.)" "I typed the
> domain name wrong, how come it doesn't work?"  "Why can't you auto-detect
> all of this?"
>
> (2) Security.  ATPS doesn't specify what stuff the third party will
> generate as you.  That third party now, practically, has one of your
> signing keys.  Suppose you decide you trust the domain owner; do you trust
> the list?  If you declare through ATPS that you trust ietf.org, and the
> list server here doesn't validate mail at ingress, then I can send
> unauthenticated mail through the list as you and it'll be as valid as if
> you signed it yourself.  That might be OK for a marketing partner you're
> paying, but it's not awesome for free mailing lists.
>

Just wanted to voice agreement on both key points.


>
> So I don't think it really helps us here, at least not in its current
> form.  Unless I've misunderstood the proposal, amending ATPS to be a
> per-user thing only trades some of the second problem for more of the first
> problem.
>
> And I think the conditional signatures ideas suffer from the same two
> issues I identified above.
>
> I also have a vague inkling that we shouldn't be talking about ATPS in a
> DMARC document because that's a layering violation, in the sense that DMARC
> is built atop DKIM and SPF, and ATPS augments DKIM.  We might get away with
> saying something like "You ought to consider things that make DKIM more
> list-tolerant", but forcing people to undertake all the DNS and user work
> that ATPS entails drags a lot of stuff into DMARC that we probably don't
> want.
>
> Personally, I think the DKIM transforms drafts stand a better chance of
> success.  They need implementation and integration with a willing MLM, and
> some experimental deployments, to see for sure.  The notion of DKIM
> transforms is also a long shot because of the complexity with which lists
> modify messages.
>

Also agreement in these points.

One possible way to understand this space might be to create a table on
trust relationships.  For example, an enterprise domain conceptually might
be willing to have an outbound gateway sign on its behalf or be willing to
delegate via something like ATPS.  Potentially there might be a similar
relationship for ESPs and their customers.  Other senders will have a
much more restrictive trust relationship.  And this is all in the abstract
as others on this list understand outbound gateway and ESPs understand
their respective members of the mailflow better than I do.

As for DKIM transforms, I just wanted to suggest that this ought to be
future work for DKIM WG.

-Wei


>
> This is not me saying we should pivot to work on these other things, at
> least not right now.  I'm just skeptical that ATPS as defined