Subject: Re: [dmarc-ietf] Been Quiet Around Here - Org Domain? Tree Walk?

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Apr 2022 18:15:23 +0200

On Mon 21/Mar/2022 23:02:03 +0100 Scott Kitterman wrote:
> On March 21, 2022 5:42:42 PM UTC, Alessandro Vesely <[email-masked]> wrote:
>>
>> According to the definition, two identical domains having psd=y 
>> are in strict alignment but not in relaxed alignment, which is 
>> somewhat counterintuitive. >
> Actually, no:
>
> "If this process does not determine the Organizational Domain, then
>     the initial target domain is the Organizational Domain."
>
> This text in DMARCbis06 addresses that case.

While that's true, it could be possible to revise the comparison 
process so as to account for identical domains.  In that case, we 
could avoid to call Organizational Domain one with no DMARC record.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Apr 2022 09:14:07 -0400

> could avoid to call Organizational Domain one with no DMARC record.

I thought I had covered this already in Section 4.8.  I'll add it to the list 
in the note.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Apr 2022 19:39:35 +0200

On Mon 04/Apr/2022 15:14:07 +0200 Scott Kitterman wrote:
>>>> somewhat counterintuitive.
>>>
>>> Actually, no:
>>>

Yeah, the text you wrote Sunday night looks better.  I'd say:

    If this process does not determine the Organizational Domain, then
    there is no Organizational Domain.

That requires rewording the definitions of relaxed alignment.  For example:

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

NEW
    In strict mode, an exact match between both Fully Qualified Domain Names
    (FQDNs) is required to produce Identifier Alignment.  In relaxed mode, an
    exact match of either both identifiers or of their respective Organizational
    Domains, if both exist, is considered to produce Identifier Alignment.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Apr 2022 18:44:50 -0400

On Monday, April 4, 2022 1:39:35 PM EDT Alessandro Vesely wrote:
> > I thought I had covered this already in Section 4.8.  I'll add it to the
> > list in the note.
> 
> exact match of either both identifiers or of their respective
> Organizational Domains, if both exist, is considered to produce Identifier
> Alignment.

So far, I don't think we've messed with those definitions.  I'd prefer not to  
change them.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 6 Apr 2022 12:05:53 +0200

On Wed 06/Apr/2022 00:44:50 +0200 Scott Kitterman wrote:
>> That requires rewording the definitions of relaxed alignment.

(Besides, we have too many definitions of alignment.)

> So far, I don't think we've messed with those definitions.  I'd prefer not to 

The point is to not have conflicting definitions.  It can be acceptable that 
the algorithm to determine the org domain finds none, if there is no org 
domain.  Currently, the org domain found by the algorithm is not necessarily 
PSD + 1.  So, it is not what we defined to be the org domain.  Isn't this 
messed up?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Apr 2022 09:22:53 -0400

On Wednesday, April 6, 2022 6:05:53 AM EDT Alessandro Vesely wrote:
> > So far, I don't think we've messed with those definitions.  I'd prefer not
> > to change them.
> 
> domain.  Currently, the org domain found by the algorithm is not
> necessarily PSD + 1.  So, it is not what we defined to be the org domain. 
> Isn't this messed up?

There are some definitional issues we need to straighten out (but not, IMO, 
ones that need to be addressed before the next revision is published.

Food for thought:

> 3.2.4.  Identifier Alignment
> 
>    When the domain in the address in the RFC5322.From header field has
>    the same Organizational Domain as a domain verified by an
>    authenticated identifier, it has Identifier Alignment. (see
>    Section 3.2.7)

An implication of that definition is that if there is no organizational domain, 
there is no alignment.  Even if 5322.From, 5321.MailFrom, and d= are the same, 
if there is no organizational domain, they are not aligned.  I think this is 
fine.  This is the reason why I added the fallback that if you don't find an 
organizational domain, the original domain is the organizational domain.

> 3.2.7.  Organizational Domain
> 
>    The Organizational Domain is typically a domain that was registered
>    with a domain name registrar.  More formally, it is any Public Suffix
>    Domain plus one label.  The Organizational Domain for the domain in
>    the RFC5322.From domain is determined by applying the algorithm found
>    in Section 4.8.

I think the second and third sentences in the current Organizational Domain 
definition conflict.  I think the second sentence should be deleted (it's not 
essential, but I believe this could be done for the next revision).

> 3.2.8.  Public Suffix Domain (PSD)
> 
>    The global Internet Domain Name System (DNS) is documented in
>    numerous RFCs.  It defines a tree of names starting with root, ".",
>    immediately below which are Top-Level Domain names such as ".com" and
>    ".us".  The domain name structure consists of a tree of names, each
>    of which is made of a sequence of words ("labels") separated by
>    period characters.  The root of the tree is simply called ".".  The
>    Internet community at large, through processes and policies external
>    to this work, selects points in this tree at which to register domain
>    names "owned" by independent organizations.  Real-world examples of
>    these points are ".com", ".org", ".us", and ".gov.uk".  Names at
>    which such registrations occur are called "Public Suffix Domains
>    (PSDs)", and a registration consists of a label selected by the
>    registrant to which a desirable PSD is appended.  For example,
>    "ietf.org" is a registered domain name, and ".org" is its PSD.

This definition works for RFC 9091.  It's an indirect way of implying "things 
in the PSL", but I don't think we need it to be so broad anymore.

In RFC 9091 we talked about multi-organization and single organization PSDs.  
For RFC 7489 + RFC 9091, that was essential, but I don't think single 
organization PSDs need special treatment anymore.  Presumably entities like 
.google can keep their own house in order.  The key element from that 
definition is 'register domain names "owned" by independent organizations'.

I think we could (and should) rework the PSD definition around that concept.

On a related note, we still need to pull the new Privacy Considerations in 
from RFC 9091 and update them for the new design.

These two things should be done in concert.  I'll work on that and provide 
something after the next revision is out.

Scott K

Scott K