[dmarc-ietf] About UAID User Agent Identity.

[Hector Santos <[e-mail]>]

On 4/20/2023 6:34 AM, Douglas Foster wrote:
> If a vendor wants to serve a customer, he needs to provide a product 
> that the customer can use.   I don't see that it is IETFs problem to 
> worry about a vendor with an inadequate email platform, especially 
> since DMARC has been around awhile.
>
> But I have been thinking further about the constrained 
> delegation issue.   The general goal, at least for a single mailing is:
> User2@Domain2 needs to be authorized to email for User1@Domain1.
>
> DKIM authorizes anyone with the private key to email for 
> anyuser@Domain1.   The domain owner has to worry about multiple things:
>
>   * Unauthorized Use For:   Will domain2 will use the key for any
>     messages other then User1@Domain1?
>   * Unauthorized Use By:   Will Others@Domain2 use the key for
>     User2@Domain2?
>   * Theft:  Will be stolen and used by HostileUser@HostileDomain.
>
> Adjusting delegation:
>
>   * Hector's ATSP proposal limits the delegation to Domain2. 
>      @HostileDomain cannot steal the delegation, because the
>     delegation only works if a domain is authenticated by @domain1
>     and has signed the message.  For a high-sensitivity domain
>     like @WhiteHouse.Gov, they may want to require both:   @Domain2
>     must have a DKIM private key for @Domain1 AND @Domain2 must have
>     an ATSP delegation from @Domin1.
>
>   * DKIMs "I=" clause can be used to limit the "Use For".  A
>     signature configured with "d=domain1; i=user1@domain1" should
>     only authenticate messages with "From: user1@domain1".   This is
>     an upward-compatible change in the way DMARC interprets DKIM,
>     not a layer violation of DKIM.   This could be used two ways: 
>     (a) possession of the private key permits use to send on behalf
>     of "user1@domain1", and (b) ATSP could provide user-level
>     delegation to only messages counter-signed by user2@domain2.
>
>   * Subdomains can be used to limit scope:   Issuing a key for
>     @subdomain1.domain1 is more limited risk than issuing a key for
>     @domain1.
>   * Subdomains with p=none can be used to allow a subset of messages
>     to be sent unauthenticated.  In some cases,
>     allowing @subdomain.domain1 to operate unauthenticated may be
>     perceived as lower risk than issuing a DKIM private key.
>
>
> The UseF
>
>
> On Wed, Apr 19, 2023 at 10:30 PM Jesse Thompson <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Wed, Apr 19, 2023, at 12:35 PM, Alessandro Vesely wrote:
>>     On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote:
>>     > To me it’s not so much the company can’t delegate authentication - it’s how
>>     > many SaaS providers (some of which are ESPs and some of which are 3rd parties
>>     > that send through ESPs) are incapable of supporting DMARC alignment. Not it’s
>>     > hard, not it’s challenging, but simply … can’t. They cannot sign with foreign
>>     > DKIM domains, and they cannot support different domains for SPF authentication.
>>     >
>>     > Should DMARCbis make the recommendation that if you are providing mail services
>>     > that you SHOULD be able to support corporate customers using DMARC?
>>
>>
>>     IMHO at least an appendix should say that if you can't do
>>     anything better you
>>     have to rewrite From: with examples of legitimate
>>     display-phrase, expanding a
>>     bit the first bullet in Section 11.4.  That can also be a good
>>     place to explain
>>     the kind of damage DMARC causes.
>
>     That's what I'm getting at. I don't really see any difference
>     between a mailing list and someone providing mail services (I
>     won't use the word ESP since that seems to be a loaded term) for
>     corporate customers (I would also add government customers, who
>     are adhering to BOD 18-01 in droves and they are also adopting
>     said companies providing mail services)
>
>     The choice for both the mailing list and mail-service company is to:
>
>     1) ignore DMARC and continue to emit mail as the original author
>     intended (the author might be ignorant of DMARC too) and assume
>     the mailbox providers are smart enough to understand that, like
>     mailing lists, mail-service companies and their mail emitting
>     authors shouldn't be caught up by a DMARC misdeployment by the
>     domain owner
>
>     2) be cognisant of DMARC's effects, and in the interest of
>     keeping the author's mail flowing, use a different domain and
>     put the author's address in the friendly from or similar, or
>     just refuse to accept the messages, until delegation can be set up.
>
>     I can say, anecdotally, that people really really want #1 to be
>     true, but they eventually learn #2 leads to a better long term
>     outcome. I'd like that "learning" to be less painful by having
>     something unambiguous to point at in DMARCbis.
>
>     Jesse
>
>

The only technical requirement for the "i=" tag is for the User Agent 
Identity (UAID) to equal the ADID (Author Domain)  (don't recall 
without looking at code).

The assessment equation extractable by reading DKIM-BASE is:

     Assessment = ASSESSOR(SDID, UAID="")

where the UAID is optional.

I argued during the drafting of DKIM-BASE to add back ADID by passing 
the ADID with SDID which is how the original DKIM modeled it:

     Assessment = ASSESSOR(ADID, SDID, UAID="")

Unfortunately, I was the only DKIM Policy advocate objecting to 
DKIM-BASE trying to, as its abstract says:

    DKIM separates the question of the identity
    of the Signer of the message from the purported author of the
    message.  Assertion of responsibility is validated through a
    cryptographic signature and by querying the Signer's domain directly
    to retrieve the appropriate public key.


So not even this backward compatible assessment was acceptable to have 
in the DKIM-BASE standard.

     Assessment = ASSESSOR(SDID, UAID="", ADID="")

For many here, the reputation of the signer trumps everything.  I 
don't think the DKIM Policy advocates ever disputed the need for 
reputation but as a final layer, not the first layer.

This is why we have had 17 years of a DKIM Policy vs DKIM Reputation 
modeling conflicts in the DKIM-related working groups.  Just keep in 
mind we have no public domain, not proposed method to do a SDID only 
assessment. But we certainly do have a several ADID::SDID assessment 
proposals!

We can't totally separate the ADID from the any SDID assessment. The 
Author ADID, From: header, is the only required header to be hashed 
bound to DKIM-Signature.  It is impossible to be  separated from 
consideration, and the irony is,  if the assessment of the signer is 
negative, it is the Author address, its MTA, its delivery agent 
(return-path) who gets hurt.

ADID can not be separated.  It is a complex situation when you are 
dealing with unsolicited mail when ADID does not equal SDID.   This is 
why DMARC can only focus with a ADID=SDID policy.

Now throw in the UAID and we have additional, complex, extended 
policies to deal with.  We don't know how to use it, optimally, 
especially for a mailing list where thousands of emails need to be 
signed.  Do you sign 1 list distribution for all  or do you sign each 
list outbound message?   Those are big scaling optimization 
considerations.

For the most exclusive policy, via DMARC:

p=reject; adkim=s; aspf=s

everything must match.

for:

p=reject; adkim=r; aspf=r

A little more relaxed for subdomains.

I think what is there is enough for this limited policy which does not 
care for users using the domain outside the main stream.

-- 
Hector Santos,
https://santronics.com
https://winserver.com