Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Douglas Foster]

Well John, we have some things to talk about, and it will have to be in
public.   You should remember that you blocked me from direct communication
when I tried to start a side conversation about improving ARC.

I conclude that I am one of the trolls that gets in your way, since I have
been driving the current topic.  You seem to be sorry for calling me names
in public, rather than repenting for the attitude behind it.
Consequently, the apology must have been intended for the chairs, and I
trust they will accept it.  For my part, I have learned to forgive quickly
because I have been forgiven of much.

For my part, I am sorry that you don't like me.I try to follow the
Biblical maxim that says, "to the extent it lies within you, live at peace
with all men."  Usually, I am successful.  I have searched my own attitude
toward this group in hopes that I am not disliked with reason.

It certainly seems that our relationship soured because I was adamantly
opposed to Dave Crocker's proposal, which repudiated From authentication as
an illegitimate concept, and sought to replace DMARC with impersonation for
everyone.   I joined this group expecting to say little and learn much, but
suddenly I was the only defender of the status quo, so silence was not an
option.

You said in the course of that discussion, "Would you be surprised if I
told you that the From address is not important to me?"   I believe you
also said that DMARC has done more harm than good.

Oddly, the chairs were happy to let the Crocker discussion fester for a
long time.   Dave frequently repeated his original assertions, without
modification, even after they had been thoroughly debunked in the
discussion.   The chairs only objected when I accused Dave of not listening
to me, which was evident.   They assured me that participants had no
obligation to listen to each other.  Eventually, Scott jumped in and
settled the matter with, "this is not DMARC."

I remain a lot confused by your change in roles.   After being DMARC's
fiercest enemy, you became entrenched as the one who controlled what
DMARCbis has become, and the current draft is unimportantly different from
the original.  I was also surprised when Scott became your strong ally.

To be clear, this has become your document.  Your most powerful weapon is
silence, but when talk is needed you have allies who will solidify your
power and your control on this document.   Nothing made this more obvious
than when you said your personal preference would override any pretense of
consensus, and the chairs let that announcement stand unchallenged.
Unfortunately, limiting the document to one viewpoint has introduced
weaknesses.   I am confident that you can move DMARCbis to publication, but
I will most likely ask for my name to be removed, since I have been
prevented from having a meaningful role in avoiding those weaknesses.

The process of creating this document has been slow, so I sympathize with
your frustration.  My wife calls this group "my mistress", because it takes
so much personal time and because it has dragged on for so long.  (It was
illuminating to hear that the original document was completed in 18
months.)   But your control works against progress, not in favor of it.
Topics which are ignored tend to keep coming back.

We have a strange and difficult assignment: a very small group of people
are supposed to figure out what is in the general interest of the large
subset of 8 billion people who will either use email or be affected by
other's use of email.   The intended path to that outcome is collaboration,
with each of us contributing our individual understanding of what is needed
to achieve that goal.   Too much of this archive is filled with
combativeness, rather than collaboration, for which I mostly blame the
chairs.

Which brings us back to my part of the collaboration.   I came to this
group from my role as an evaluator of an incoming mail stream, frustrated
with the vendors who are supposed to protect us, and eager to find a way to
improve email defenses against the combined effects of malicious actors and
bungling vendors.  I had little experience with mailing lists, and my early
participation was not sympathetic to them.  But the Crocker discussion did
change me.   I have been looking, ever since, for ways to bring mailing
lists into the authentication world, even while expressing my frustration
that the problem is one of their own making.

After multiple other options have been considered and failed, I have landed
on ATPS as a solution which is pretty well suited to the problem that the
Crocker proposal was trying to fix.   It is a very serious proposal, and
not an attempt to waste your time.   I hoped you and other mailing list
advocates would be excited, and hoped that you specifically would turn your
considerable brain power toward turning the concept into reality.  Instead,
you are annoyed and the other power players have been oddly silent.

I am ready to collaborate on 

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Hector Santos]

Barry,  

This is wrong. He knows his post was not off-list. His defamation of my 
character is out of line. But he does it to those disagrees with. He is 
smarting than all of us. So nothing knew.

Levine, editor of ADSP and the editor DMARCbis, needs to finally support DKIM 
Policy or give up editorship to a DKIM Policy Advocate engineer who does.

You will see how fast it will be finished.  This document will not change 
anything regarding p=reject but only promote a rewrite, tearing down DMARC 
security  as the only solution. Even if he refuses to write about it  he uses 
it to tear down the very essence of the document purpose in life.

The long time interference with the high interest for a DKIM Policy solution 
needs to finally end. 

—
HLS

> On Apr 22, 2023, at 5:22 PM, John Levine  wrote:
> 
> [[ rather off list ]]
> 
> I think we all established a long time ago that the Internet that
> Hector uses is very unlike the one the rest of us use, and it's not
> worth arguing with him.
> 
> That said, I really wish the chairs would shut down the trolls.  They may
> not think they're trolls, but they are having the classing trolling effect
> of wasting time and driving people away.
> 
> R's,
> John
> 
> 
> It appears that Dotzero  mailto:dotz...@gmail.com>> said:
>> -=-=-=-=-=-
>> 
>> On Sat, Apr 22, 2023 at 2:04 PM Hector Santos > 40isdg@dmarc.ietf.org> wrote:
>> 
>>> 
>>> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
>>> 
>>> It appears that Jesse Thompson   said:
>>> 
>>> -=-=-=-=-=-
>>> 
>>> A DNS-based lookup, perhaps in the style of ATSP as this thread is
>>> describing, to query for not just domain-level authorization, but also
>>> potentially user-level authorization, I think is
>>> compelling because it can:
>>> 
>>> 
>>> Once again, no. This is not mission creep, it is mission gallop.
>>> 
>>> 
>>> The current mission is chaos!!  I sometimes wonder If the intent is to
>>> keep it chaotic to show non-consensus in really the strategy.  Jesse was
>>> referring to user policies.  ATPS is about domain policies.  Lets not
>>> confuse this.
>>> 
>>> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
>>> distraction and wheel spinning that is keeping us from finishing.
>>> 
>>> 
>>> -1
>>> 
>>> First, not true, there is running code using ATPS, and you know it.
>>> Second, there are APIs that support it.  It may be disabled in the open
>>> source but it's there. Second, when an editor does not champion his own
>>> work, it will be much harder to sell.  There is absolute no reason why a
>>> receiver can not to an ATPS check if its already doing an DMARC with false
>>> positive results due to not doing an ATPS.
>>> 
>>> What has kept us from finishing this 17+ year project was the editor of
>>> ADSP and now editor of DMARCbis preventing 3rd party authorization
>>> concepts.  He removed it from SSP when it was hijacked with ADSP.   To his
>>> credit, its on the record, he didn’t want people using ADSP and was
>>> successful to get it abandoned as a proposed standard and made it historic.
>>> 
>> 
>> You are incorrect that SSP was "hijacked" by ADSP.  I was the one who
>> suggested the change from Sender Signing Protocol to Author Domain Signing
>> Protocol because the effort was about domains and NOT individuals. It was
>> ONLY a name change. As with many other efforts there was evolution, both
>> before the name change (which occurred around SSP 11 if I remember
>> correctly) and after. Anyone can go back to the list archives to verify
>> this.
>> 
>>> 
>>> But DMARC snuck in via M3 as an Informational status and since he can’t
>>> stop domains from using DMARC, he took over the editing of DMARCbis and now
>>> wants a MUST NOT p=reject without explaining how to best avoid its problems
>>> for existing systems.
>>> 
>> 
>> As one of the original organizers of the DMARC effort I object to your
>> characterization of DMARC as having "snuck in via M3". The DMARC effort
>> coalesced when an earlier effort called MOOCOW organized by JD Falk failed.
>> (I had declined to participate in MOOCOW because I believed early on that
>> it was doomed to fail.) Yes, some of the DMARC meetings took place
>> immediately preceding M3 meetings as a matter of convenience but many more
>> took place online or were hosted by participating organizations at their
>> offices. There were also other efforts as well. Anyone can go back to the
>> archives of lists like DKIM-OPS circa 2007 to see me publicly stating a
>> DMARC like approach in which I said that any emails being emitted by
>> americangreetings.com that failed to pass either DKIM signed mail with a
>>> From of americangreetings.com or SPF aligned with americangreetings.com
>> should be discarded. This differed from the effort between PayPal and Yahoo
>> which was based on private peering between two parties.
>> 
>> As I have previously stated on this list, I disagree with the MUST NOT for
>> p=reject but I think you casting aspersions that John 

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[John Levine]

 [[ rather off list ]]

I think we all established a long time ago that the Internet that
Hector uses is very unlike the one the rest of us use, and it's not
worth arguing with him.

That said, I really wish the chairs would shut down the trolls.  They may
not think they're trolls, but they are having the classing trolling effect
of wasting time and driving people away.

R's,
John


It appears that Dotzero   said:
>-=-=-=-=-=-
>
>On Sat, Apr 22, 2023 at 2:04 PM Hector Santos 40isdg@dmarc.ietf.org> wrote:
>
>>
>> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
>>
>> It appears that Jesse Thompson   said:
>>
>> -=-=-=-=-=-
>>
>> A DNS-based lookup, perhaps in the style of ATSP as this thread is
>> describing, to query for not just domain-level authorization, but also
>> potentially user-level authorization, I think is
>> compelling because it can:
>>
>>
>> Once again, no. This is not mission creep, it is mission gallop.
>>
>>
>> The current mission is chaos!!  I sometimes wonder If the intent is to
>> keep it chaotic to show non-consensus in really the strategy.  Jesse was
>> referring to user policies.  ATPS is about domain policies.  Lets not
>> confuse this.
>>
>> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
>> distraction and wheel spinning that is keeping us from finishing.
>>
>>
>> -1
>>
>> First, not true, there is running code using ATPS, and you know it.
>> Second, there are APIs that support it.  It may be disabled in the open
>> source but it's there. Second, when an editor does not champion his own
>> work, it will be much harder to sell.  There is absolute no reason why a
>> receiver can not to an ATPS check if its already doing an DMARC with false
>> positive results due to not doing an ATPS.
>>
>> What has kept us from finishing this 17+ year project was the editor of
>> ADSP and now editor of DMARCbis preventing 3rd party authorization
>> concepts.  He removed it from SSP when it was hijacked with ADSP.   To his
>> credit, its on the record, he didn’t want people using ADSP and was
>> successful to get it abandoned as a proposed standard and made it historic.
>>
>
>You are incorrect that SSP was "hijacked" by ADSP.  I was the one who
>suggested the change from Sender Signing Protocol to Author Domain Signing
>Protocol because the effort was about domains and NOT individuals. It was
>ONLY a name change. As with many other efforts there was evolution, both
>before the name change (which occurred around SSP 11 if I remember
>correctly) and after. Anyone can go back to the list archives to verify
>this.
>
>>
>> But DMARC snuck in via M3 as an Informational status and since he can’t
>> stop domains from using DMARC, he took over the editing of DMARCbis and now
>> wants a MUST NOT p=reject without explaining how to best avoid its problems
>> for existing systems.
>>
>
>As one of the original organizers of the DMARC effort I object to your
>characterization of DMARC as having "snuck in via M3". The DMARC effort
>coalesced when an earlier effort called MOOCOW organized by JD Falk failed.
>(I had declined to participate in MOOCOW because I believed early on that
>it was doomed to fail.) Yes, some of the DMARC meetings took place
>immediately preceding M3 meetings as a matter of convenience but many more
>took place online or were hosted by participating organizations at their
>offices. There were also other efforts as well. Anyone can go back to the
>archives of lists like DKIM-OPS circa 2007 to see me publicly stating a
>DMARC like approach in which I said that any emails being emitted by
>americangreetings.com that failed to pass either DKIM signed mail with a
>>From of americangreetings.com or SPF aligned with americangreetings.com
>should be discarded. This differed from the effort between PayPal and Yahoo
>which was based on private peering between two parties.
>
>As I have previously stated on this list, I disagree with the MUST NOT for
>p=reject but I think you casting aspersions that John is trying to kill
>DMARC is baseless and unfair. He has strong opinions about interoperability
>and mail lists.
>
>
>>
>> Yet, his answer to the DMARC problem, as a single implementation with IETF
>> list, is to strip the security of a domain using a Rewrite and does not
>> want to document it as a DMARCBis solution to the problem he refuses to
>> help fix, nor document the subscription/submission restrictions method,
>> something he could have done rather than introduce an unfortunate mail
>> engineering taboo to they industry - a new security loophole with caused by
>> this rewrite:
>>
>>  Destroyed Mail Authorship Authentication Replays
>>
>> I almost believe he wants DMARCBis to fail as a Proposed Standard,
>> therefore refusing to also change it back to informational status as
>> suggested by Barry Leibre since it would give DMARCbis a better chance of
>> surviving IETF engineering scrutiny and passing last call.
>>
>> As a proposed standard, there will be friction when 

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Dotzero]

On Sat, Apr 22, 2023 at 2:04 PM Hector Santos  wrote:

>
> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
>
> It appears that Jesse Thompson   said:
>
> -=-=-=-=-=-
>
> A DNS-based lookup, perhaps in the style of ATSP as this thread is
> describing, to query for not just domain-level authorization, but also
> potentially user-level authorization, I think is
> compelling because it can:
>
>
> Once again, no. This is not mission creep, it is mission gallop.
>
>
> The current mission is chaos!!  I sometimes wonder If the intent is to
> keep it chaotic to show non-consensus in really the strategy.  Jesse was
> referring to user policies.  ATPS is about domain policies.  Lets not
> confuse this.
>
> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
> distraction and wheel spinning that is keeping us from finishing.
>
>
> -1
>
> First, not true, there is running code using ATPS, and you know it.
> Second, there are APIs that support it.  It may be disabled in the open
> source but it's there. Second, when an editor does not champion his own
> work, it will be much harder to sell.  There is absolute no reason why a
> receiver can not to an ATPS check if its already doing an DMARC with false
> positive results due to not doing an ATPS.
>
> What has kept us from finishing this 17+ year project was the editor of
> ADSP and now editor of DMARCbis preventing 3rd party authorization
> concepts.  He removed it from SSP when it was hijacked with ADSP.   To his
> credit, its on the record, he didn’t want people using ADSP and was
> successful to get it abandoned as a proposed standard and made it historic.
>

You are incorrect that SSP was "hijacked" by ADSP.  I was the one who
suggested the change from Sender Signing Protocol to Author Domain Signing
Protocol because the effort was about domains and NOT individuals. It was
ONLY a name change. As with many other efforts there was evolution, both
before the name change (which occurred around SSP 11 if I remember
correctly) and after. Anyone can go back to the list archives to verify
this.

>
> But DMARC snuck in via M3 as an Informational status and since he can’t
> stop domains from using DMARC, he took over the editing of DMARCbis and now
> wants a MUST NOT p=reject without explaining how to best avoid its problems
> for existing systems.
>

As one of the original organizers of the DMARC effort I object to your
characterization of DMARC as having "snuck in via M3". The DMARC effort
coalesced when an earlier effort called MOOCOW organized by JD Falk failed.
(I had declined to participate in MOOCOW because I believed early on that
it was doomed to fail.) Yes, some of the DMARC meetings took place
immediately preceding M3 meetings as a matter of convenience but many more
took place online or were hosted by participating organizations at their
offices. There were also other efforts as well. Anyone can go back to the
archives of lists like DKIM-OPS circa 2007 to see me publicly stating a
DMARC like approach in which I said that any emails being emitted by
americangreetings.com that failed to pass either DKIM signed mail with a
>From of americangreetings.com or SPF aligned with americangreetings.com
should be discarded. This differed from the effort between PayPal and Yahoo
which was based on private peering between two parties.

As I have previously stated on this list, I disagree with the MUST NOT for
p=reject but I think you casting aspersions that John is trying to kill
DMARC is baseless and unfair. He has strong opinions about interoperability
and mail lists.


>
> Yet, his answer to the DMARC problem, as a single implementation with IETF
> list, is to strip the security of a domain using a Rewrite and does not
> want to document it as a DMARCBis solution to the problem he refuses to
> help fix, nor document the subscription/submission restrictions method,
> something he could have done rather than introduce an unfortunate mail
> engineering taboo to they industry - a new security loophole with caused by
> this rewrite:
>
>  Destroyed Mail Authorship Authentication Replays
>
> I almost believe he wants DMARCBis to fail as a Proposed Standard,
> therefore refusing to also change it back to informational status as
> suggested by Barry Leibre since it would give DMARCbis a better chance of
> surviving IETF engineering scrutiny and passing last call.
>
> As a proposed standard, there will be friction when ADSP was abandoned for
> reasons DMARCBis is not resolving other than saying don’t use restrictive
> domains.   That’s what slowing this down.
>

ADSP (nee SSP) had other issues and it wasn't so much killed as failed.
There were agreed upon compromises and it failed to gain traction. That
sometimes happens.

I'll also digress and address Jim Fenton's comment about the Federal
government not understanding the difference between informational and
Standards track. DMARC wasn't submitted to IETF as informational until
2015. It was originally published 

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Hector Santos]

> On Apr 22, 2023, at 12:58 PM, John Levine  wrote:
> 
> It appears that Jesse Thompson   said:
>> -=-=-=-=-=-
>> 
>> A DNS-based lookup, perhaps in the style of ATSP as this thread is 
>> describing, to query for not just domain-level authorization, but also 
>> potentially user-level authorization, I think is
>> compelling because it can:
> 
> Once again, no. This is not mission creep, it is mission gallop.

The current mission is chaos!!  I sometimes wonder If the intent is to keep it 
chaotic to show non-consensus in really the strategy.  Jesse was referring to 
user policies.  ATPS is about domain policies.  Lets not confuse this.

> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
> distraction and wheel spinning that is keeping us from finishing.

-1

First, not true, there is running code using ATPS, and you know it.  Second, 
there are APIs that support it.  It may be disabled in the open source but it's 
there. Second, when an editor does not champion his own work, it will be much 
harder to sell.  There is absolute no reason why a receiver can not to an ATPS 
check if its already doing an DMARC with false positive results due to not 
doing an ATPS.

What has kept us from finishing this 17+ year project was the editor of ADSP 
and now editor of DMARCbis preventing 3rd party authorization concepts.  He 
removed it from SSP when it was hijacked with ADSP.   To his credit, its on the 
record, he didn’t want people using ADSP and was successful to get it abandoned 
as a proposed standard and made it historic. 

But DMARC snuck in via M3 as an Informational status and since he can’t stop 
domains from using DMARC, he took over the editing of DMARCbis and now wants a 
MUST NOT p=reject without explaining how to best avoid its problems for 
existing systems.

Yet, his answer to the DMARC problem, as a single implementation with IETF 
list, is to strip the security of a domain using a Rewrite and does not want to 
document it as a DMARCBis solution to the problem he refuses to help fix, nor 
document the subscription/submission restrictions method, something he could 
have done rather than introduce an unfortunate mail engineering taboo to they 
industry - a new security loophole with caused by this rewrite:

 Destroyed Mail Authorship Authentication Replays

I almost believe he wants DMARCBis to fail as a Proposed Standard, therefore 
refusing to also change it back to informational status as suggested by Barry 
Leibre since it would give DMARCbis a better chance of surviving IETF 
engineering scrutiny and passing last call.

As a proposed standard, there will be friction when ADSP was abandoned for 
reasons DMARCBis is not resolving other than saying don’t use restrictive 
domains.   That’s what slowing this down.

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

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[Douglas Foster]

I am aware nobody is using ATSP.  I have not seen an assessment of why
nobody.  The current implementation seems competitive with DKIM, which is
my explanation for it's failure.

Extending ATSP for user-to-domain, would address new functionality which
addresses the large unsolved problem in our charter.   Evading the problem
by telling people not to use DMARC is not a solution.

Admitting failure is an option, and I have been close to that on several
occasions.   But as of today, I think failure is unnecessary.   I think the
data hiding problem can be solved.

I also like Ale's recipient authentication approach.   The two approaches
can be used in parallel.

DF




On Sat, Apr 22, 2023, 12:58 PM John Levine  wrote:

> It appears that Jesse Thompson   said:
> >-=-=-=-=-=-
> >
> >A DNS-based lookup, perhaps in the style of ATSP as this thread is
> describing, to query for not just domain-level authorization, but also
> potentially user-level authorization, I think is
> >compelling because it can:
>
> Once again, no. This is not mission creep, it is mission gallop.
>
> Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
> distraction and wheel spinning that is keeping us from finishing.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

[John Levine]

It appears that Jesse Thompson   said:
>-=-=-=-=-=-
>
>A DNS-based lookup, perhaps in the style of ATSP as this thread is describing, 
>to query for not just domain-level authorization, but also potentially 
>user-level authorization, I think is
>compelling because it can:

Once again, no. This is not mission creep, it is mission gallop.

Nobody uses ATSP, nobody is going to use ATSP, this is just yet more
distraction and wheel spinning that is keeping us from finishing.

R's,
John

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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

Here is an scenario I long envisioned with high-valued services implementing a 
DKIM Policy model.

Example: bank and a new online banking customer:

Bank:  "For online banking we need an email address for secured private email 
communications."

User:  "hmm, user.n...@esp1-domain.com "

Bank:  "OK, let me check its security………please wait…."

Bank does some DNS lookups and finds no DKIM POLICY record. At the time,  it 
was SSP, ADSP, DSAP.  Imagine today, the bank checks DMARC and finds no record 
for esp1-example.com .

Bank:  "I’m sorry, this email address is not considered secured. Do you have 
another?"

User:  "Yes, I have another.n...@esp2-domain.com 
 try that."

Bank sees the domain has a SPF all? neutral policy and a DMARC p=none policy.

Bank:  "Mr. User, this email address is not secured for our secured banking 
needs with your new online account. How about we assigned you a new secured 
bank address.  new.u...@secured-users.bank.net 
”

User:  "Ok, but wow, another address I have to remember??  Can I use my 
iCloud.com account?

Bank: “iCloud.com is a secured domain.  You can use that email.”

So the user had the option to use a secure domain account or the user would be 
assigned one by the service.

That’s how I saw it high-value transactions and companies moving,   That 
special address MAY BE a 3rd party too bank authorized via ATPS.

The unsecured domain ESP user simply can not be used with private services 
where the data exchanges need to be 100% transported authenticated and 
authorized.   The current practice with the majority of MLM, at least as I 
experienced with then IETF list, break the security in the name of not stopping 
the mail flow.


---
HLS


> On Apr 22, 2023, at 9:53 AM, Jesse Thompson  wrote:
> 
> On 4/22/2023 6:20 AM, Alessandro Vesely wrote:
>> Those kinds of sender-side authorization schemes seem to be designed for 
>> ESP-like businesses, where a domain owner delegates Domain2 to send messages 
>> on its behalf.  Using such schemes for mailing lists, thereby going down to 
>> per-user records sounds improper and bloats the amount of DNS stuff.
> Does it bloat DNS more than DNSBLs do? Would it make more sense if it were 
> done via HTTPS?
> 
> Here's what I see in the real world:
> * Organization's policy dictates "use a subdomain" for non-general-purpose 
> use cases. 
> * Legacy non-general-purpose use of the org domain is tolerated because there 
> is no easy migration path. 
> * People within the organization instinctively want to use the org domain.
> * They're very confused how it works technically, they try to pull strings to 
> get what they want.
> * Eventually a person high enough in the organization intervenes.
> * So, the domain owner has no choice but to authorize the ESP to use the 
> entire org domain, yet again.
> 
> Why is it improper for a domain owner to have an ability to delegate 
> per-user? I understand that it may be technically infeasible, but why is it 
> improper?
> 
> I'm still not certain why ESPs are fundamentally different than mailing lists.
> ESP: A message author confirms their identity with the ESP and asks the ESP 
> to emit mail with their rfc5322.From address
> MLM: A message author confirms their identity with the MLM and asks the MLM 
> to emit mail with their rfc5322.From address
> 
> 
> 
>> To address mailing list and forwarding for address portability, I'd rather 
>> devise receiver-side schemes, whereby the final receiver acknowledges that 
>> the email address of a user of its has been written to a file that produces 
>> mailing list of forwarding effects, while the author domain is not involved 
>> at all.  A very rough idea here:
>> https://datatracker.ietf.org/doc/draft-vesely-email-agreement/
> 
> A scheme like this seems just as applicable to ESPs as it does mailing lists, 
> insofar as mutual consensus of confirmed opt-in can be achieved between all 3 
> parties.
> 
> 
>> "Upon user confirmation, that MTA itself confirms the subscription to the 
>> MLM."
> 
> Since you mentioned this enables address portability: If the user changes 
> mailbox providers, how do they communicate all of their prior confirmed 
> subscriptions to the MTA? How does the MLM know if the confirmed 
> subscriptions have not been back-filled?
> 
> Jesse
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

> On Apr 21, 2023, at 10:19 PM, Douglas Foster 
>  > wrote:
> 
> I mean something different.
> 
> By "user-to-domain" I mean a DNS function which asserts:
> When the message is signed by IETF, and the From address is my account, the 
> message is considered authenticated by this DNS entry.
> If the message is signed by IETF but the From address is a different account 
> in the same domain, the message is not authenticated by this DNS entry.o
That’s the conceptual TPA protocol theory.  Consider SPF has a TPA system when 
the possible external MTA (smtp client machine) was “authorized” by IP address. 
  It took a while before domains were adding -include _spf.google.com 
 to their SPF primary domain records.  Conceptually, 
that is what ATPS, TPA, DSAP ideas offered to DKIM+ADSP and now DKIM+DMARC.   

> We have three uses cases:
> The owner of an account on a mailbox provider such as Gmail, who wants to 
> create an ESP account for mass mailings.   Girl Scout troops were mentioned 
> as a community that had this problem after the Yahoo lockdown.
> 
> The subscriber to a mailing list who wants to authorize the list owner to 
> send messages using his From identity.  We all have this problem.
> 
> And the newly introduced problem of the domain owner who is not willing to 
> delegate a DKIM scope.   They might be willing to authorize the ESP to send 
> messages on behalf of market...@example.com , 
> until they realize that it also authorizes the ESP to send on behalf of 
> c...@example.com  .   The ESP is willing to accept a 
> DKIM scope, but the management sees the delegation as too risky.

1) This scenario is a typical one.  Mailing list had early esp domains, 
yahoo.com , gmail.com , msn.com 
, so many that become “spam-polluted” that at one point, I was 
among those calling for a flat out block of these highly abusive domains.I 
give many kudos for AOL.COM  to start with a hard reject with 
SPF and jump start the MARID working group that began the SPF and the DKIM era. 
 YAHOO.COM  finally said enough with DMARC p=reject and why 
not? Yahoo invented DomainKeys with the reject concept "o=-“ tag on the 
signature, no DNS lookup needed. So no one should be surprise that the patented 
idea finally was activated via DMARC p=reject.   

2) This scenario is also typical - the subscriber with DNS control of the 
domain to add an authorization record.  That would be me and a good bit of the 
developers here.

3) This is not new. In fact, it has been the #1 reason for DKIM with a POLICY 
enforcement concept.  It is the #1 payoff.  It was the strongest, the most 
restrictive policy. Original DKIM had o=- which was split into SSP with other 
o= signing patterns, which was replaced with ADSP with Discardable and now 
DMARC with p=reject.  The concept was so powerful,  the Functional 
Specification for SSP indicated that it MUST NOT trump local policy.What 
happen with DMARC causing From Rewrite is a reminder of local policy can not be 
controlled by author domain policy.

> 
> To solve these use cases, we need a DNS lookup that is based on the fully 
> qualified From address and the DKIM domain.   In concept, it seems like a 
> straightforward extension of any of the third-party signing strategies.   


The Domain Policy Model I believe is sufficient than a Domain User Policy.  It 
would also be Using email address would need to be manageable via DNS.
 
TPA has scoping logic that was too complex for me to follow.  ATPS was simpler. 
   You might follow Doug Otis’s TPA better than I did.

> 
> What I see as the primary difficulty is the need to publish a DNS entry which 
> is specific to my email account, without announcing to every spammer in the 
> world that my account is an available spam target.Hashing helps, but 
> creates collisions.   To avoid side-channel authorizations, we need a way to 
> disaggregate collisions.   ATSP does that by providing the domain name in 
> cleartext, but that I don't see that as acceptable for a user account.   Some 
> critics may argue that hashing is not an adequate data-hiding technique 
> anyway,
> 
> It would be the solution to the great mailing list problem if we can make it 
> work.   But is that possible?


We can make anything happen with software changes.  This requires changes to 
legacy mail unit operations, MSA, MDA, MLS, MTA, the C/C++ SMTP developers, the 
Mail Men, the transporters, and changes to the "low code”  that makes up MLM 
scipts for the Administrators.

For a long time, starting with FidoNet [1] and also with the IETF too, I 
experienced a good bit of the debates with future methods and directions was 
often a clash between Developers vs Administrators.  Basically software 
developers want to do it right - cross all the tees, dot 

Re: [dmarc-ietf] Delegated authentication for Gmail

[Jesse Thompson]

On 4/22/2023 6:20 AM, Alessandro Vesely wrote:
> Those kinds of sender-side authorization schemes seem to be designed for 
> ESP-like businesses, where a domain owner delegates Domain2 to send messages 
> on its behalf.  Using such schemes for mailing lists, thereby going down to 
> per-user records sounds improper and bloats the amount of DNS stuff.
Does it bloat DNS more than DNSBLs do? Would it make more sense if it were done 
via HTTPS?

Here's what I see in the real world:
* Organization's policy dictates "use a subdomain" for non-general-purpose use 
cases. 
* Legacy non-general-purpose use of the org domain is tolerated because there 
is no easy migration path. 
* People within the organization instinctively want to use the org domain.
* They're very confused how it works technically, they try to pull strings to 
get what they want.
* Eventually a person high enough in the organization intervenes.
* So, the domain owner has no choice but to authorize the ESP to use the entire 
org domain, yet again.

Why is it improper for a domain owner to have an ability to delegate per-user? 
I understand that it may be technically infeasible, but why is it improper?

I'm still not certain why ESPs are fundamentally different than mailing lists.
ESP: A message author confirms their identity with the ESP and asks the ESP to 
emit mail with their rfc5322.From address
MLM: A message author confirms their identity with the MLM and asks the MLM to 
emit mail with their rfc5322.From address



> To address mailing list and forwarding for address portability, I'd rather 
> devise receiver-side schemes, whereby the final receiver acknowledges that 
> the email address of a user of its has been written to a file that produces 
> mailing list of forwarding effects, while the author domain is not involved 
> at all.  A very rough idea here:
> https://datatracker.ietf.org/doc/draft-vesely-email-agreement/

A scheme like this seems just as applicable to ESPs as it does mailing lists, 
insofar as mutual consensus of confirmed opt-in can be achieved between all 3 
parties.


> "Upon user confirmation, that MTA itself confirms the subscription to the 
> MLM."

Since you mentioned this enables address portability: If the user changes 
mailbox providers, how do they communicate all of their prior confirmed 
subscriptions to the MTA? How does the MLM know if the confirmed subscriptions 
have not been back-filled?

Jesse

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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Alessandro Vesely]

Those kinds of sender-side authorization schemes seem to be designed for 
ESP-like businesses, where a domain owner delegates Domain2 to send messages on 
its behalf.  Using such schemes for mailing lists, thereby going down to 
per-user records sounds improper and bloats the amount of DNS stuff.


To address mailing list and forwarding for address portability, I'd rather 
devise receiver-side schemes, whereby the final receiver acknowledges that the 
email address of a user of its has been written to a file that produces mailing 
list of forwarding effects, while the author domain is not involved at all.  A 
very rough idea here:

https://datatracker.ietf.org/doc/draft-vesely-email-agreement/


Best
Ale
--

On Fri 21/Apr/2023 00:24:56 +0200 Douglas Foster wrote:
Murray's ATSP proposal (https://www.ietf.org/rfc/rfc6541.txt 
) and Hector's DSAP proposal 
(https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00 
) have a 
similar goal:   Allow "Domain2" to send authenticated messages for "Domain1".

This is authorized when

  * the message is signed by "Domain2" and
  * a DNS entry in "Domain1" is configured to authorizes "Domain2" as a
delegated signer.

(I will use RFC6541 as my primary reference because it seems to have avoided 
scaling problems.)


A mailbox account owner cannot benefit from these ideas because he needs the 
ability to define a user-authorizes-domain or user-authorizes-user 
relationship.   Consequently, we should extend the RFC 6541 design to support a 
subkey of the form:

     ._users.._atsp...

Query sequence:

  * The initial query is for an ATSP policy at
._atsp..  If it returns a result that
authorizes the signatures, the search stops.
  * If the query returns NXDOMAIN, no further search is needed because the
_users subkey does not exist.
  * Otherwise, a second query is performed for an ATSP policy at
._Users.._atsp ..  If a valid
result is found, the signature is also authorized.  T

The DNS entries for user-level authentication would be created automatically by 
the mailbox provider upon request from the user.


This approach gives the mailbox provider the ability to control which delegated 
domains are allowed.   If a third-party signer is badly behaved, the mailbox 
domain could remove all of its delegated signing entries and prevent new ones.  
  A potential downside is that the mailbox provider could use this power to 
limit third-party signing to its favorite sister companies or favorite business 
partners, possibly in exchange for payment or other favorable actions.


This approach is also a path forward for the mailing list problem.   If a 
user's domain implements user-level ATSP delegation of signing rights, each 
subscriber documents his participation in the mailing list by requesting a 
user-level delegation for the list server's domain.


The mailing list can easily check the ATSP entries for its subscribers to see 
if delegated signing authority has been granted.    The greater difficulty is 
knowing whether recipient domains implement support for the concept.  But the 
design does not require mailing lists to make any changes to benefit from the 
design, which has been a big obstacle to other concepts.


What are the objections?

Doug Foster



.

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


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