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:
> <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
