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