Subject: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

From: Todd Herr <[email-masked]>
Date: Tue, 7 Dec 2021 07:36:42 -0500

Greetings.

I've been engaged in a spirited off-list discussion regarding the topic of
relaxed alignment and the idea of a required relationship between two
domains in relaxed alignment. I won't reveal the other party in the
discussion, but I thought it best to bring the topic to the list to get
consensus and clarity.

The question central to the debate I'm having is this:

Given example.com as the Organizational Domain, are a.b.c.example.com and
d.e.f.example.com in relaxed alignment?

I contend that, as currently written, RFC 7489 and dmarcbis-04 contain text
that puts those two domains in relaxed alignment. The text at issue
supporting this claim is in RFC 7489 in sections 3.1.1 and 3.1.2, and in
dmarcbis-04 in sections 4.7.1 and 4.7.2 and reads as follows:

In relaxed mode, the Organizational Domains of both the DKIM-authenticated
signing domain (taken from the value of the d= tag in the signature) and
that of the RFC5322.From domain must be equal if the identifiers are to be
considered to be aligned. In strict mode, only an exact match between both
Fully Qualified Domain Names (FQDNs) is considered to produce Identifier
Alignment.

In relaxed mode, the Organizational Domains of the SPF-authenticated domain
and RFC5322.From domain must be equal if the identifiers are to be
considered to be aligned. In strict mode, the two FQDNs must match exactly
in order for them to be considered to be aligned.

My partner in the off-list discussion maintains that other text in RFC 7489
makes clear that the domains must have an hierarchical relationship (i.e.,
one must be a subdomain of the other) in order to be in relaxed alignment,
and that this was the intent of the original authors. Examples of such text
include the following:

RFC 7489, section 3.1:

Relaxed mode can be used when the operator also wishes to affect message
flows bearing subdomains of the verified domains.

RFC 7489, section 3.1.1:

   To illustrate, in relaxed mode, if a validated DKIM signature

   successfully verifies with a "d=" domain of "example.com", and the

   RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From
address is "[email-masked]", the DKIM "d="

   domain and the RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From domain are
considered to be "in

   alignment".  In strict mode, this test would fail, since the "d="

   domain does not exactly match the FQDN of the address.

RFC 7489, section 3.1.2:

   For example, if a message passes an SPF check with an

   RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom
domain of "cbg.bounces.example.com", and the address

   portion of the RFC5322
<https://datatracker.ietf.org/doc/html/rfc5322>.From field contains
"[email-masked]",

   the Authenticated RFC5321
<https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain
identifier and the

   RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain
are considered to be "in alignment" in relaxed

   mode, but not in strict mode.

Further, it seems to be the most common use case for relaxed alignment to
be accomplished with domains that have a direct descendant relationship
with each other, not just the common ancestor of the organizational domain.

So, what is the consensus of the group here? If there MUST be a direct
descendant relationship between two domains in order for them to be in
relaxed alignment, then it seems that the text I cited above should be
changed to explicitly state that. On the other hand, if there's no such
requirement, I believe that should be explicitly called out, too, in order
to avoid misunderstanding in the future.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2021 12:00:58 -0500

It appears that Todd Herr  <[email-masked]> said:
>-=-=-=-=-=-

Yes, of course.

>one must be a subdomain of the other) 

That's not what it says.  The examples happen to be subdomains but the spec
is the text, not the examples.

>with each other, not just the common ancestor of the organizational domain.

That's not unreasonable, but it would be a change, and I don't see any advantage
compared to leaving the current rule alone.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 Dec 2021 19:28:44 +0000

>compared to leaving the current rule alone.

Agreed.  Examples are only that.  People need to implement the rules as written, not assume if their code gets the examples right that means it's correct (which is my wild speculation about what happened).

Scott K

---

From: Dotzero <[email-masked]>
Date: Tue, 7 Dec 2021 15:54:23 -0500

Interesting responses to your post..

On Tue, Dec 7, 2021 at 7:37 AM Todd Herr <todd.herr=
[email-masked]> wrote:

> I contend that, as currently written, RFC 7489 and dmarcbis-04 contain
> text that puts those two domains in relaxed alignment. The text at issue
> In relaxed mode, the Organizational Domains of the SPF-authenticated
> domain and RFC5322.From domain must be equal if the identifiers are to be
> My partner in the off-list discussion maintains that other text in RFC
> 7489 makes clear that the domains must have an hierarchical relationship
> (i.e., one must be a subdomain of the other) in order to be in relaxed
> alignment, and that this was the intent of the original authors. Examples
> of such text include the following:
>
> RFC 7489, section 3.1:
>
>    RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From address is "[email-masked]", the DKIM "d="
>
>    domain and the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain are considered to be "in
>
>    RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain of "cbg.bounces.example.com", and the address
>
>    portion of the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field contains "[email-masked]",
>
>    the Authenticated RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain identifier and the
>
>    RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain are considered to be "in alignment" in relaxed
>

Let us consider that DNS is hierarchical. A subdomain cannot exist unless
those responsible for the parent/organizational domain create it through
DNS. We know to some extent that a relationship exists between a domain and
it's subdomains. What can we know about the relationship between sister
domains? Basically nothing. By allowing sister domains to act as "aligned"
we enable a potential ly gaping security hole in various cases. In fact,
those cases where the abuse is most likely involve folks who are likely to
be unaware of or lacking understanding of email authentication and how it
works.

Consider buildium.com, which provides property management software and
states " Every Buildium subscription comes with a custom subdomain -
*http://yoursubdomainhere.managebuilding.com
<http://yoursubdomainhere.managebuilding.com>*. Depending on your needs,
you may want to use another name when talking with clients, residents,
friends, and family." None of the users of these subdomains has a
relationship with each other besides purchasing services from a common
provider. John Levine and Scott Kitterman clearly see no opportunity for
abuse by ill intentioned people in a scenario like this. A bad person would
never use an SPF record from imreallynotabadguy.buildingmanagement.com to
send an email with a FROM of innocentcustomer.buildingmanagement.com in
anticipation of suckering those with relationships with innocentcustomer.

Let's consider that there are still some ESPs who like to have
(particularly smaller) customers use subdomains on their platform for
various reasons. It might be that using subdomains from a common
organizational domain is easier to manage than using domains/subdomains
provided by the customer(s) or delegated by the customer(s). It might be
that the ESP believes that existing customers in this scenario can "lend"
reputation to new customers and/or dilute badness from a reputation
perspective. Again, this sort of situation can allow unrelated entities to
align and potentially get a DMARC pass through relaxed alignment which
allows for sister domains.

Many hosting sites for wordpress and other basic websites offer the use of
subdomains as well. Again we might ask the question as to what the
relationship of these sister domains is to each other? Should one be able
to align and authenticate against it's siblings? Should an IETF standard
knowingly allow and enable potential malicious behavior? We know that "bad
guys" have been early adopters of email authentication. Anyone think there
aren't bad guys subscribed to this list and thinking about the
possibilities for abuse of this mechanism?

Michael Hammer

---

From: Todd Herr <[email-masked]>
Date: Tue, 7 Dec 2021 15:59:47 -0500

On Tue, Dec 7, 2021 at 3:54 PM Dotzero <[email-masked]> wrote:

> states " Every Buildium subscription comes with a custom subdomain - *http://yoursubdomainhere.managebuilding.com
Why do aspf=s and adkim=s not mitigate the risks you're discussing here?

--

---

From: Dotzero <[email-masked]>
Date: Tue, 7 Dec 2021 16:14:04 -0500

On Tue, Dec 7, 2021 at 4:00 PM Todd Herr <todd.herr=
[email-masked]> wrote:

>> never use an SPF record from imreallynotabadguy.buildingmanagement.com
>> to send an email with a FROM of innocentcustomer.buildingmanagement.com
>> in anticipation of suckering those with relationships with innocentcustomer.
>>
>> Many hosting sites for wordpress and other basic websites offer the use
>> of subdomains as well. Again we might ask the question as to what the
> You obviously don't remember the "Your Momma" session at <redacted>.
> Someone unsophisticated enough to be using subdomains from someone else
> just isn't very likely to be sophisticated when it comes to security and
> email authentication. Now you have me thinking about creating a scanner for
> these types of scenarios and releasing it publicly as a "security tool". It
> might even make a nice module for SET (Social Engineer Toolkit. I wonder
> how long it would take to be used and abused?
>

Michael Hammer.

---

From: Seth Blank <[email-masked]>
Date: Tue, 7 Dec 2021 13:20:58 -0800

I'm very confused. The conversation was about relaxed alignment, which
requires the org domains to be the same, but not necessarily subsets of one
another. This is the operational case today, where a.example.com and
b.example.com are relaxed aligned.

+1 to John and Scott.

On Tue, Dec 7, 2021 at 1:14 PM Dotzero <[email-masked]> wrote:

>>> Let us consider that DNS is hierarchical. A subdomain cannot exist
>>> unless those responsible for the parent/organizational domain create it
>>> through DNS. We know to some extent that a relationship exists between a
>>> domain and it's subdomains. What can we know about the relationship between
>>> sister domains? Basically nothing. By allowing sister domains to act as
>>> "aligned" we enable a potential ly gaping security hole in various cases.
>>> In fact, those cases where the abuse is most likely involve folks who are
>>> likely to be unaware of or lacking understanding of email authentication
>>> and how it works.
>>>
>>> <http://yoursubdomainhere.managebuilding.com>*. Depending on your
>>> needs, you may want to use another name when talking with clients,
>>> residents, friends, and family." None of the users of these subdomains has
>>> a relationship with each other besides purchasing services from a common
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank * | Chief Product Officer
*e:* [email-masked]
*p:* 415.273.8818

---

From: Todd Herr <[email-masked]>
Date: Tue, 7 Dec 2021 17:11:01 -0500

>> You obviously don't remember the "Your Momma" session at <redacted>.
Not true. My aunt was one of the guest panelists. The session was held to
allow email professionals to gain insight on how regular older people
interacted with the email they receive on a daily basis. I distinctly
recall my aunt replying "I just spam it" in response to a question about
how she reacted to receiving some type of email or other.

>> email authentication.
So you're suggesting that the protocol be adapted to the people using it,
rather than people implement the protocol as is?

> Now you have me thinking about creating a scanner for these types of
>> scenarios and releasing it publicly as a "security tool". It might even
>> make a nice module for SET (Social Engineer Toolkit. I wonder how long it
>> would take to be used and abused?
>>
>
>
I will accept neither guilt nor blame for your actions.
--

---

From: Dotzero <[email-masked]>
Date: Tue, 7 Dec 2021 17:31:12 -0500

> rather than people implement the protocol as is?

No, I'm suggesting that if a protocol is written knowing that it introduces
opportunities for abuse it should be fixed to mitigate the potential for
that abuse.

> I will accept neither guilt nor blame for your actions.

It appears you are also unwilling to accept any guilt or blame for
knowingly producing a protocol that you know can enable abuse. Whether I
were to create such a tool or somebody else produces such a tool, the
simple act of discussing the underlying issue on a public list like this
puts it into play.

Happy Holidays.

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 Dec 2021 17:53:12 -0500

On Tuesday, December 7, 2021 3:54:23 PM EST Dotzero wrote:
> >    RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom domain
> >    of "cbg.bounces.example.com", and the address
> >    
> >    portion of the RFC5322
> >    RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain are
> >    considered to be "in alignment" in relaxed
> >    

The question posed was what does RFC 7489 say (along with the text in the 
draft which is not changed), not what should it say.

RFC 7489 says what it says and none of the above changes that.

If you want to suggest that we should change it, I'd suggest back off the ad 
homonym attacks, chill, and start over.  Since you can read my mind because I 
"clearly see no opportunity for abuse by ill intentioned people" despite me 
never having said that, there's really no need for me to read any of this 
thread.

If someone wants to have a non-abusive version of this conversation, I'm all 
for it.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Tue, 7 Dec 2021 22:03:23 -0500

If there was any confusion about the meaning of the old spec, this
discussion seems to have highlighted the points where it needs
clarification.
To preserve v=1, we need to preserve the broader definition of same
organization.   But yes, the discussion diverged from "what does it say?"
to "what should it say?"

My understanding of the concern is that some domain owners act as PSDs.   I
think we have addressed that concern with the PSD flag.
Assume that "vendordomain.tld" is the service provider and his clients send
as "clientname.clients.vendorname.tld".   By setting the PSD flag on
"clients.vendordomain.tld", the vendor ensures that each of his clients are
handled as separate organizations.   He can still email as
"vendordomain.tld" and "othersubdomains.vendordomain.tld", but he will be
unable to mail anything as "clients.vendordomain.tld"

Of course, if he was not savvy enough to use a subdomain to serve as parent
to the clients, the solution may not work.   If his clients are
"clientname.vendordomain.tld" and he sets the PSD flag on
"vendordomain.tld", he ensures client separation, but he can no longer
email using his own domain of "vendordomain.tld".   This may not be a
problem.   My ISP uses ".net" as the TLD for clients, and ".com" for their
own mail.

The principle is that as long as the parent of the client domains is not
used to send mail, the PSD flag keeps the clients separate.

As I think Todd said, using an organization-level policy which requires
strict matching will also help.

Michael:   Does this address all of your concerns, or is there more to
consider?

Doug Foster

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2021 22:51:57 -0500

It appears that Dotzero  <[email-masked]> said:
>abuse by ill intentioned people in a scenario like this.

Wow, I am impressed that you totally completely fail to understand what
organizational domains are, how they work, and what that point of the
PSL is.

This is *exactly* the problem that made Mozilla invent the PSL in the
first place.  There is the minor difference that their question is whether
foo.xxx.yyy and bar.xxx.yyy can share web browser cookies, but it's
the same question, are they "they same" entity.

If the people running managebuilding.com were more on the ball, they
would open a ticket with the PSL and get added, but as you note
they are not and they haven't.  I hope they don't let their customers
run web servers on those subdomains because the opportunity for
mischief is if anything more than from mail spoofing.

I don't think it's a bad idea to redefine alignment so that one
domain has to be a parent of the other, but it's an incompatible
change and it's not what the code does now.  Since we're expecting
people to change from PSL to a tree walk, this is as good a
time as any to consider other changes.

The new way to check whether two names are in relaxed alignment would
be to start at the longer one and walk up the tree to the shorter one.
If there aren't any DMARC records in between, they're aligned. If the
longer one is an immediate descendant of the other, they're always
aligned unless I suppose if the shorter one says it's a PSD.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Tue, 7 Dec 2021 22:59:39 -0500

John suggests:

"The new way to check whether two names are in relaxed alignment would be
to start at the longer one and walk up the tree to the shorter one."

I thought about this some.   A variant of this would be to start from the
longest common substring, which could be used on sister domains, and seems
efficient.  But neither of these approaches will protect the FROM address
correctly.   The walk MUST start from the FROM domain, regardless of which
name is longer, because that is the name which is being validated.

Doug

---

From: Seth Blank <[email-masked]>
Date: Tue, 7 Dec 2021 20:26:28 -0800

As an individual and thinking out loud, I'm concerned about redefining
relaxed alignment. Adding more granularity provided by a tree walk is one
thing (i.e. adding lookups between the author domain and the org domain),
but changing the mechanism altogether to change these anchors is another.
Modifying relaxed alignment is a breaking change-- and operationally it's
clear that most everyone using DMARC (there was data on this list a few
months ago) is only using relaxed alignment, which is working as intended.

The other side, is that there are tickets asking if we should strike strict
alignment, since it is rarely used and adds confusion to implementation and
operation.

Perhaps this is the appropriate way to redefine strict alignment to be
meaningful, instead of throwing it out?

i.e. relaxed alignment stays the same: both domains share a common ancestor
which is longer than a PSD (which would need a solid formal definition)
      and then strict alignment is that one domain must be a descendant of
the other, without an interstitial PSD

Thoughts?

--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Dec 2021 05:05:26 +0000

John is right.  The postulated entity should be on the PSL in the private section.  It's this kind of situation that convinced me that my suggestion about only using the public part of the PSL was a bad idea.

Nothing is going to save end users from poorly run hosts.  The market has to solve it.

The good news is, as I think it was Doug mentioned in the part of this thread I'm ignoring, the entity can add the psd flag to their DMARC record (or not publish one, I think) and the problem can be solved without reference to an external entity and waiting for PSL updates to be made and distributed.

Modulo user hostile providers, I don't think this is a problem.  Nothing needs changing we haven't already changed.

Also, strict may be rarely used, but I would imagine those that have gone to the trouble to set it up have reasons for doing so.  Let's not mess that up over a non-problem.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 8 Dec 2021 13:41:44 +0100

Hi,

I don't think alignment definitions should be modified.  We can add, for 
example, adkim=h, for hierarchical, if we want to restrict DKIM signers to be 
super or sub domains of the From: domain.

The advantage of this definition is that it doesn't require to determine the 
org domain, until org domains cannot publish DKIM keys.

Best
Ale

-------- Original Message --------
Subject: Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and 
Domain Hierarchy
Date: Tue, 7 Dec 2021 20:26:28 -0800
From: Seth Blank <[email-masked]>
To: IETF DMARC WG <[email-masked]>

Thoughts?

--