Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Scott Kitterman]

On April 20, 2023 4:18:08 PM UTC, Dotzero  wrote:
>On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:
>
>> It appears that Alessandro Vesely   said:
>> >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.
>>
>> Absolutely not. This sort of thing is utterly outside the scope of our
>> job and wasting time on it just further delays our already extremely
>> late work.
>>
>> R's,
>> John
>>
>
>+1
>
>There are many things John and I may disagree on but he clearly understands
>why avoiding scope creep (and bad ideas) is important.

Definitely agree with both of you on this.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Delegated authentication for Gmail

[Douglas Foster]

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:
._users.._atsp...

Query sequence:

   - The initial query is for an ATSP policy at
   ._atsp..  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
   ._Users.._atsp ..  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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Hector Santos]

> On Apr 19, 2023, at 10:29 PM, Jesse Thompson  wrote:
> 
> 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

This will cause the list bounce problem.  This was seen immediately in the IETF 
list when it 100% ignorance of DKIM.  Signatures broke.  

Solution: Support DKIM and resign as 3rd party
Problem: Policy does not allow a resigner.

No one honored broken signatures, policies. Recorded as fail but no lost until 
YAHOO shook the world and began to honor p=reject policies.  Bounce problem.


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

We allowed a protocol incomplete to take off without dealing with the known 
potential problem.  No one will honor DKIM policy stuff.

Now its broken.

As a Mailing List Server developer, we need a migration path to a 3rd option 
(ATPS concept) which using #2 temporarily.   Ideally no From destruction is the 
goal.  For now, I use #2 restrictions on subscription and submissions 

—
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] About UAID User Agent Identity.

[Hector Santos]

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

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Dotzero]

On Thu, Apr 20, 2023 at 11:38 AM John Levine  wrote:

> It appears that Alessandro Vesely   said:
> >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.
>
> Absolutely not. This sort of thing is utterly outside the scope of our
> job and wasting time on it just further delays our already extremely
> late work.
>
> R's,
> John
>

+1

There are many things John and I may disagree on but he clearly understands
why avoiding scope creep (and bad ideas) is important.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[John Levine]

It appears that Alessandro Vesely   said:
>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.

Absolutely not. This sort of thing is utterly outside the scope of our
job and wasting time on it just further delays our already extremely
late work.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Douglas Foster]

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