Subject: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Dec 2021 23:02:20 -0800

This was reported but not sent to the WG.  I believe the right disposition
is "Hold for Document Update".  Does anyone want to argue for "Rejected" or
"Verified"?

-MSK

---------- Forwarded message ---------
From: RFC Errata System <[email-masked]>
Date: Mon, Nov 1, 2021 at 4:31 PM
Subject: [Technical Errata Reported] RFC7489 (6729)
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

The following errata report has been submitted for RFC7489,
"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6729

--------------------------------------
Type: Technical
Reported by: Scott Kitterman <[email-masked]>

Section: 3.2

Original Text
-------------
   3.  Search the public suffix list for the name that matches the
       largest number of labels found in the subject DNS domain.  Let
       that number be "x".

Corrected Text
--------------
   3.  Search the ICANN DOMAINS section of the public suffix list for
       the name that matches the largest number of labels found in the
       subject DNS domain.  Let that number be "x".

Notes
-----
The PSL includes both public and private domains.  RFC 7489 should have
limited name matching to the public, ICANN DOMAINS section of the PSL.  As
an example, using the current PSL, the organizational domain for
example.s3.dualstack.ap-northeast-1.amazonaws.com is
example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since
it is listed in the private section of the PSL.  This is clearly the wrong
result.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7489 (draft-kucherawy-dmarc-base-12)
--------------------------------------
Title               : Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Publication Date    : March 2015
Author(s)           : M. Kucherawy, Ed., E. Zwicky, Ed.
Category            : INFORMATIONAL
Source              : INDEPENDENT
Area                : N/A
Stream              : INDEPENDENT
Verifying Party     : ISE & Editorial Board

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2021 13:00:25 -0500

It appears that Murray S. Kucherawy  <[email-masked]> said:
>-=-=-=-=-=-

Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
local policy.

I also think that Scott's example in the notes is wrong.  It is perfectly
plasuble for an operator's customers to have their own DMARC policy, although most
of the subdomains are less exotic than this one.  Try Centralic's us.com
where I think you would not want foo.us.com and bar.us.com to share the
same default policy.

R's,
John

>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Dec 2021 15:53:08 -0500

I must agree with Mr Levine on this.

tim

On Sat, Dec 4, 2021 at 1:00 PM John Levine <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Seth Blank <[email-masked]>
Date: Sat, 4 Dec 2021 14:02:50 -0800

> where I think you would not want foo.us.com and bar.us.com to share the

+1

Scott's example, which he states as wrong, is in fact correct.

The org domain should in fact be
example.s3.dualstack.ap-northeast-1.amazonaws.com and not amazonaws.com, as
amazonaws.com is not the organization which controls policy for, or should
receive reports for, the organization which has registered and is using
example.s3.dualstack.ap-northeast-1.amazonaws.com.

Seth, as an individual

-- 

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

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: Scott Kitterman <[email-masked]>
Date: Sun, 05 Dec 2021 03:17:34 +0000

As discussion after I had filed this makes clear, my proposed solution isn't a great one.  Since we're well on our way towards removing PSL use from the DMARC revision, I don't think it matters a lot whether we reject it or hold for document update and mark it resolved when the new revision is finalized.

Although it is certainly a corner case, I think it's illustrative of why getting away from the PSL for this use will be a good thing.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 5 Dec 2021 12:18:29 +0100

On Sat 04/Dec/2021 23:02:50 +0100 Seth Blank wrote:
>> plasuble for an operator's customers to have their own DMARC policy, 
>> although most of the subdomains are less exotic than this one.  Try
>> Centralic's us.com where I think you would not want foo.us.com and
>> bar.us.com to share the same default policy. >
> +1
> 

+1

While I agree that editing the PSL before giving it as a parameter to a DMARC 
filter is a question of local policy, a discussion on the effects produced by 
varying the attribution of org domains is required, especially now that we are 
enabling domains to freely appoint themselves as PSDs.

Best
Ale
--