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 > <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 > <mailto: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: >> <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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
