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 <[email protected]> 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 > <https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-ssp/> > datatracker.ietf.org > <https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-ssp/> > [image: ietf-logo-nor-180.png] > <https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-ssp/> > <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 < > [email protected]> 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 < > [email protected]> 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: >> <hasheduser>._users.<hashed-domain>._atsp.<parent-domain>.. >> >> Query sequence: >> >> - The initial query is for an ATSP policy at >> <hashed-domain>._atsp.<parent-domain>. 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 >> <hasheduser>._Users.<hashed-domain>._atsp .<parent-domain>. 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
