Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

> 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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

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.

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

> 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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

Re: [dmarc-ietf] Delegated authentication for Gmail

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

[dmarc-ietf] Delegated authentication for Gmail

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