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] Is From spoofing an interoperability issue or not?

[Scott Kitterman]

On April 21, 2023 3:57:54 PM UTC, Alessandro Vesely  wrote:
>On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote:
>> On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:
>>> On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:
 It appears that Alessandro Vesely   said:
 
> IMHO at least an appendix should say that if you can't do anything better 
> you have to rewrite From: with examples of legitimate display-phrase, 
> expanding a bit the first bullet in Section 11.4. That can also be a good 
> place to explain the kind of damage DMARC causes. >>>
 Absolutely not. This sort of thing is utterly outside the scope of our job 
 and wasting time on it just further delays our already extremely late work.
>>> 
>>> +1
>>> 
>>> There are many things John and I may disagree on but he clearly understands 
>>> why avoiding scope creep (and bad ideas) is important.
>> 
>> Definitely agree with both of you on this.
>
>
>Eeeh, what an uprising!  I just proposed a couple of paragraphs, not a new 
>rocket science theory.
>
>As for the badness, why wouldn't a concise but detailed explanation be better 
>than obscure forbiddings and dark forebodings, such as MUST NOT be used by 
>humans or interoperability will break down?
>
>BTW, what's the outcome of that discussion?

That, specifically is a question for the chairs, so no idea.

There are a nearly infinite set of few paragraphs we could write that would 
make things clearer.  If we ever want to finish this, some of them need to be 
out of scope.

Scott K

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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Alessandro Vesely]

On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote:

On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

It appears that Alessandro Vesely   said:

IMHO at least an appendix should say that if you can't do anything 
better you have to rewrite From: with examples of legitimate 
display-phrase, expanding a bit the first bullet in Section 11.4. 
That can also be a good place to explain the kind of damage DMARC 
causes. >>>
Absolutely not. This sort of thing is utterly outside the scope of our 
job and wasting time on it just further delays our already extremely 
late work.


+1

There are many things John and I may disagree on but he clearly understands 
why avoiding scope creep (and bad ideas) is important.


Definitely agree with both of you on this.



Eeeh, what an uprising!  I just proposed a couple of paragraphs, not a new 
rocket science theory.


As for the badness, why wouldn't a concise but detailed explanation be better 
than obscure forbiddings and dark forebodings, such as MUST NOT be used by 
humans or interoperability will break down?


BTW, what's the outcome of that discussion?


Best
Ale
--




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

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