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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Jesse Thompson]

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:

* Give domain owners a mechanism to achieve least-privilege authorization of 
3rd parties; limiting blast radius

* Enable delegated authorization of all sending streams within mixed-use 
domains; not just telling the mixed-use domain owners they are "doing things 
wrong" and they can't use DMARC as a result

* Make it clear to intermediaries that they do not need to reject or rewrite, 
assuming they know if the receiver understands they are authorized (but then 
again, they may not need to care either way, if they are still living in a 
mindset where DMARC doesn't exist)


On Fri, Apr 21, 2023, at 6:15 AM, Douglas Foster wrote:
> Thinking on this some more, there are some tricky design risks:

I appreciate the thoughts you have put on this topic. It may not be feasible, 
but I think it's worth exploring user-level authorization.


> If the user-to-domain delegation scheme exposes an email address to the 
> world, that information may be used for unwanted purposes, particularly 
> increased spam volumes.   Hashing provides part of that solution.   The ATSP 
> document solves this problem by using a mix of hash and cleartext domain 
> name, but we should not expose a cleartext username.

Perhaps a query to a domain-level salt would help limit rainbow tables 
reversing the hashed usernames. If it's only worth creating rainbow tables for 
mega-domains, which already have a saturated namespace, I assume the spammers 
see less value in knowing if any address within the namespace is valid.

Reversible hashed usernames do present an opportunity for domain owners to 
publish false ATSP records for spam trap purposes. win-win?

The privacy risk is less of a concern if the address is no-reply@. But the 
privacy risk is real for normal users authorizing mailing lists.


> Hash algorithms are intended to create enough collisions so that reversing 
> the hash is not practical, but the lookup process needs to ensure uniqueness 
> so that a delegation record does not create unauthorized secondary 
> delegations.

But domain-level delegation creates infinite user-level delegations today. I 
don't think this is worth obsessing about if people think domain-level 
delegation is secure enough.


> Similarly, the domain owner needs a way to clean up his DNS when an account 
> is terminated.   This includes removing delegations for the terminated 
> account without causing mistakes caused by hash collisions.   So some form of 
> tiebreaker will be needed to ensure uniqueness.

I was thinking the larger issue is that DNS administrators would have a hard 
time keeping track of which user address is associated with each hash. 
Especially if their DNS software/provider doesn't offer an internal 
comment/tagging capability. They'll have to maintain an internal lookup table.

What are the chances that because userA is authorized to use a mail-provider, 
that userB (who is a hash collision, whatever the long odds) begins to start 
using the same mail-provider, and then the DNS admin cleans up the userA 
authorization and accidentally breaks userB? It seems unlikely.


> Mitigation ideas:

> A user-to-domain delegation always uses plus addressing.  This increases 
> randomness of the hash process and adds complexity to hash-reversal attacks.  
>  It also simplifies privacy recovery if the plus address is compromised.

This seems challenging for the mailing list use case. I don't think most users 
have an easy way to send from a plussed address.


> The delegation record lookup uses a hash key based on the authorizing user 
> and the signing domain concatenated together, and a secondary key based on 
> the signing domain alone.   I don't know whether it will be better to look up 
> the signing domain using hash or cleartext.

I think rainbow tables could still be created based on common usernames and 
common signing domains. Why not require the domain owner to use and publish a 
salt instead? Or maybe both?


> To handle the hopefully rare case where a hash collision still occurs, the 
> domain owner creates multiple delegation records and assigns them a record 
> number which is used internally to associate a specific record with a 
> specific user account.

They would still need a lookup table of some sort.


> Doug
> 
> On Thu, Apr 20, 2023 at 6:24 PM 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 

Re: [dmarc-ietf] Delegated authentication for Gmail

[Douglas Foster]

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.

We have three uses cases:

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

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

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


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.

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?

Doug Foster








On Fri, Apr 21, 2023 at 4:47 PM Hector Santos  wrote:

>
> > On Apr 21, 2023, at 2:14 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >
> > Can it provide a user-to-domain authentication solution?
>
> Unless I am not following you, DKIM inherently provides "user-to-domain"
> authentication by hash binding the 5322 From: and To: headers.
>
> > That is what mailing lists need and that is what mailbox provider
> clients need.  These use cases are pretty fundamental to our objective of
> getting mail authenticated without causing damage
>
> A mailing list is a 1 to Many distribution.  Legacy mail integrity lost
> was a normal practice for a list system, i.e, footers. Well, technically
> no.  For DKIM, if you used the l= content length tag and did not change the
> subject line, the original signature could survive.
>
>
> GMAIL could easily provide a box for their users that authorized signers
> and MTAs.  Come inbound time, it can check for the authorize the MTA and
> 3rd party signer.
>
> What I am missing, Google boys? 
>
>
> —
> HLS
>
>
>
>
___
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 2:14 PM, Douglas Foster 
>  wrote:
> 
> Can it provide a user-to-domain authentication solution?   

Unless I am not following you, DKIM inherently provides "user-to-domain" 
authentication by hash binding the 5322 From: and To: headers.  

> That is what mailing lists need and that is what mailbox provider clients 
> need.  These use cases are pretty fundamental to our objective of getting 
> mail authenticated without causing damage 

A mailing list is a 1 to Many distribution.  Legacy mail integrity lost was a 
normal practice for a list system, i.e, footers. Well, technically no.  For 
DKIM, if you used the l= content length tag and did not change the subject 
line, the original signature could survive. 


GMAIL could easily provide a box for their users that authorized signers and 
MTAs.  Come inbound time, it can check for the authorize the MTA and 3rd party 
signer.  

What I am missing, Google boys? 


—
HLS



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

Re: [dmarc-ietf] Delegated authentication for Gmail

[Douglas Foster]

Can it provide a user-to-domain authentication solution?   That is what
mailing lists need and that is what mailbox provider clients need.  These
use cases are pretty fundamental to our objective of getting mail
authenticated without causing damage

Or has everyone already decided that user-to-domain delegation is
impossible?

On Fri, Apr 21, 2023, 1:44 PM Hector Santos  wrote:

> Doug,
>
> You might want review Doug Otis’s TPA (Third Party Authorization).  It has
> a higher scale method.
>
> DKIM Third-Party Authorization for Sender Signer Practices
> 
> datatracker.ietf.org
> 
> [image: ietf-logo-nor-180.png]
> 
> 
>
> Abstract
>
>
> TPA-label is a DNS-based prefix mechanism for DKIM policy records as a
> means to authorize Third-Party domains. This mechanism allows first-party
> domains to autonomously authorize a range of third-party domains in a
> scalable, individual DNS transaction. This authorization extends the scope
> of DKIM policy assertions to supplant more difficult to administer
> mechanisms. Alternatives for facilitating third-party authorizations
> currently necessitate the coordination between two or more domains by
> setting up selector/key DNS records, DNS zone delegations, or the regular
> exchange of public/ private keys. Checking DKIM policies may occur when a
> From header email-address is not within the domain of a valid DKIM
> signature. When a Third-Party signature is found, TPA-labels offer an
> efficient means for email address domains to authorize specific third-party
> signing domains. The scope of the authorization may separately assert
> identity authentication for From and Sender and Resent-* headers for email-
> addresses within the authorizing domain. Identity authentication can be
> asserted by the scope of the authorization, even when signed by a
> Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize
> domains for controlling DSNs.
> —
> HLS
>
>
> On Apr 21, 2023, at 7:15 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> Thinking on this some more, there are some tricky design risks:
>
>- If the user-to-domain delegation scheme exposes an email address to
>the world, that information may be used for unwanted purposes, particularly
>increased spam volumes.   Hashing provides part of that solution.
> The ATSP document solves this problem by using a mix of hash and cleartext
>domain name, but we should not expose a cleartext username.
>
>- Hash algorithms are intended to create enough collisions so that
>reversing the hash is not practical, but the lookup process needs to ensure
>uniqueness so that a delegation record does not create unauthorized
>secondary delegations.   Similarly, the domain owner needs a way to clean
>up his DNS when an account is terminated.   This includes removing
>delegations for the terminated account without causing mistakes caused by
>hash collisions.   So some form of tiebreaker will be needed to
>ensure uniqueness.
>
> Mitigation ideas:
>
>- A user-to-domain delegation always uses plus addressing.  This
>increases randomness of the hash process and adds complexity to
>hash-reversal attacks.   It also simplifies privacy recovery if the plus
>address is compromised.
>- The delegation record lookup uses a hash key based on the
>authorizing user and the signing domain concatenated together, and a
>secondary key based on the signing domain alone.   I don't know whether it
>will be better to look up the signing domain using hash or cleartext.
>- To handle the hopefully rare case where a hash collision still
>occurs, the domain owner creates multiple delegation records and assigns
>them a record number which is used internally to associate a specific
>record with a specific user account.
>
> Doug
>
> On Thu, Apr 20, 2023 at 6:24 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> 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:

Re: [dmarc-ietf] Delegated authentication for Gmail

[Hector Santos]

Doug,

You might want review Doug Otis’s TPA (Third Party Authorization).  It has a 
higher scale method. 

https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-ssp/

Abstract


TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to 
authorize Third-Party domains. This mechanism allows first-party domains to 
autonomously authorize a range of third-party domains in a scalable, individual 
DNS transaction. This authorization extends the scope of DKIM policy assertions 
to supplant more difficult to administer mechanisms. Alternatives for 
facilitating third-party authorizations currently necessitate the coordination 
between two or more domains by setting up selector/key DNS records, DNS zone 
delegations, or the regular exchange of public/ private keys. Checking DKIM 
policies may occur when a From header email-address is not within the domain of 
a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer 
an efficient means for email address domains to authorize specific third-party 
signing domains. The scope of the authorization may separately assert identity 
authentication for From and Sender and Resent-* headers for email- addresses 
within the authorizing domain. Identity authentication can be asserted by the 
scope of the authorization, even when signed by a Third-Party domain. In 
addition, the RFC2821.MailFrom domain can authorize domains for controlling 
DSNs.

—
HLS


> On Apr 21, 2023, at 7:15 AM, Douglas Foster 
>  wrote:
> 
> Thinking on this some more, there are some tricky design risks:
> If the user-to-domain delegation scheme exposes an email address to the 
> world, that information may be used for unwanted purposes, particularly 
> increased spam volumes.   Hashing provides part of that solution.   The ATSP 
> document solves this problem by using a mix of hash and cleartext domain 
> name, but we should not expose a cleartext username.
> 
> Hash algorithms are intended to create enough collisions so that reversing 
> the hash is not practical, but the lookup process needs to ensure uniqueness 
> so that a delegation record does not create unauthorized secondary 
> delegations.   Similarly, the domain owner needs a way to clean up his DNS 
> when an account is terminated.   This includes removing delegations for the 
> terminated account without causing mistakes caused by hash collisions.   So 
> some form of tiebreaker will be needed to ensure uniqueness.
> Mitigation ideas:
> A user-to-domain delegation always uses plus addressing.  This increases 
> randomness of the hash process and adds complexity to hash-reversal attacks.  
>  It also simplifies privacy recovery if the plus address is compromised.
> The delegation record lookup uses a hash key based on the authorizing user 
> and the signing domain concatenated together, and a secondary key based on 
> the signing domain alone.   I don't know whether it will be better to look up 
> the signing domain using hash or cleartext.
> To handle the hopefully rare case where a hash collision still occurs, the 
> domain owner creates multiple delegation records and assigns them a record 
> number which is used internally to associate a specific record with a 
> specific user account.
> Doug
> 
> On Thu, Apr 20, 2023 at 6:24 PM 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 

Re: [dmarc-ietf] Delegated authentication for Gmail

[Douglas Foster]

Thinking on this some more, there are some tricky design risks:

   - If the user-to-domain delegation scheme exposes an email address to
   the world, that information may be used for unwanted purposes, particularly
   increased spam volumes.   Hashing provides part of that solution.
The ATSP document solves this problem by using a mix of hash and cleartext
   domain name, but we should not expose a cleartext username.

   - Hash algorithms are intended to create enough collisions so that
   reversing the hash is not practical, but the lookup process needs to ensure
   uniqueness so that a delegation record does not create unauthorized
   secondary delegations.   Similarly, the domain owner needs a way to clean
   up his DNS when an account is terminated.   This includes removing
   delegations for the terminated account without causing mistakes caused by
   hash collisions.   So some form of tiebreaker will be needed to
   ensure uniqueness.

Mitigation ideas:

   - A user-to-domain delegation always uses plus addressing.  This
   increases randomness of the hash process and adds complexity to
   hash-reversal attacks.   It also simplifies privacy recovery if the plus
   address is compromised.
   - The delegation record lookup uses a hash key based on the authorizing
   user and the signing domain concatenated together, and a secondary key
   based on the signing domain alone.   I don't know whether it will be better
   to look up the signing domain using hash or cleartext.
   - To handle the hopefully rare case where a hash collision still occurs,
   the domain owner creates multiple delegation records and assigns them a
   record number which is used internally to associate a specific record with
   a specific user account.

Doug

On Thu, Apr 20, 2023 at 6:24 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> 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-ietf] Delegated authentication for Gmail

[Douglas Foster]

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