Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John Levine]

In article  
you write:
>Can you provide more details, please?
>
>Are you receiving reports by HTTPS, or have you not seen any reduction in
>reports, or both, or other?

I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set 
up
a web server to catch any POST or PUT traffic.

Other than a few Russian probes shortly after I published it, it's
gotten no traffic at all.

I suppose the good news is that nobody implemented the underspecifed
report URL in one of the earlier DMARC drafts.

R's,
John

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John Levine]

In article  
you write:
>My mention of "other concerns ... about privacy and security" is in
>reference to a post in this thread that Mike Hammer made in early December,
>where he wrote:
>
>"I don't recall a strong security and privacy concerns discussion around
>HTTP(S) reporting. Presumably the report contents are protected in transit
>but to what extent is access by arbitrary parties an issue. Notwithstanding
>that things like GDPR are political issues, they are worth noting as a real
>life operational consideration."

I saw this but I still don't understand it. The chances of an HTTP
POST getting snooped on are far less than any kind of e-mail.

R's,
John

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Tue, Jan 19, 2021 at 2:11 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> No Murray, I was speaking to the PSD document.
>
> PSD's entire purpose is to detect abuse of non-existent organizational
> domains, so the definition of non-existent is crucial to its success.I
> believe the current language will produce false positives, albeit probably
> a small number.The current language is also more resource-intensive
> than mine, although that is not my concern.
>

What I mean is: If we say PSD experiment participants evaluate the notion
of "non-existent" differently than vanilla DMARC implementations, we have
to account for that when interpreting the results of the experiment.  But
the experiment as crafted is just to determine if the PSD algorithm as
proposed is a useful improvement.  It seems to me that changing the nature
of that test at the same time is scope creep that muddies the waters.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Douglas Foster]

No Murray, I was speaking to the PSD document.

PSD's entire purpose is to detect abuse of non-existent organizational
domains, so the definition of non-existent is crucial to its success.I
believe the current language will produce false positives, albeit probably
a small number.The current language is also more resource-intensive
than mine, although that is not my concern.

I believe this is also a general problem that full DMARC should address.
 If a domain exists but does not have a policy, we interpret this to mean
that the domain owner has not chosen to publish a policy, which is his
right.If a domain does not exist, then there is no domain owner to
publish a policy and no reason to believe that the use of the domain is
legitimate.   In fact, use of an unregistered domain is a violation of IETF
policy and the entire name registration infrastructure.Consequently, I
believe that SPF and DMARC SHOULD differentiate between "policy not
specified" and NXDOMAIN.   But to put this topic into play for DMARC, I
need to create a ticket, right?

I also want PSD to use a correct definition of non-existent because it will
establish a precedent for any generalization done as part of the full DMARC
effort.

Doug Foster

On Tue, Jan 19, 2021 at 9:23 AM Murray S. Kucherawy 
wrote:

> On Tue, Jan 19, 2021 at 4:34 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I raised objections to the definition of "non-existent", which never
>> received an adequate response before the discussion went silent.
>>
>> DMARC checks the From  header address, which may exist only as an
>> identifier used for mass mailings.   These mailings are often sent by an
>> ESP using an unrelated SMTP address.As such, the From address need not
>> be associated with any A, , or MX record.I assert that the only
>> viable definition of non-existent is "not registered", as evidenced by
>> absence of an NS record.
>>
>
> This is a discussion of DMARC, not of PSD, right?  DMARC defines this test
> in an Appendix, and then makes it non-mandatory.  PSD says to apply that
> test for domains that request it.
>
> Hooking this test up to registration requires introducing RDAP or
> something similar.  Is that what we're talking about here?
>
> I don't believe the proposed definition of "non-existent" is reliably true
>> even in the special case of interest for this document, impersonation fraud
>> occurring at the top of an organizational structure.  Example.PSD may
>> legitimately use mail.Example.PSD for email and www.example.psd for web.
>>  If the proposed condition MUST always be true, I have not seen that fact
>> demonstrated.   Since the document raises a general concern about
>> fraudulent use of non-existent domains, the definition used should be one
>> that can be generalized.,
>>
>
> This sounds like something that should be solved in DMARC, not PSD, but
> naturally consensus wins here, so have at it.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #80 - DMARCbis Should Have Clear and Concise Definition of DMARC

[Todd Herr]

I am going to close this ticket.

I have opened ticket 96, Tweaks to Abstract and Introduction
, for Ale's suggestions and for
any tweaks that John might still suggest.


On Tue, Jan 5, 2021 at 8:36 AM Todd Herr  wrote:

> On Tue, Jan 5, 2021 at 7:25 AM Alessandro Vesely  wrote:
>
>> On Thu 31/Dec/2020 20:24:59 +0100 John Levine wrote:
>> > In article > 6...@mail.gmail.com> you write:
>> >>
>> >>Dave Crocker submitted some suggestions on-list, and I noodled a bit
>> with
>> >>the text myself, and submit the following for your collective
>> consideration:
>> >
>> > I have a few minor editorial tweaks to suggest but they can wait.  I
>> think
>> > we should use this text.
>>
>>
>> +1, I see it's not yet on github.  Please go ahead, possibly posting a
>> .txt as
>> well, so we can run IETF's diff tool.
>>
>>
>>
> Updated version, including .txt but without your suggested minor tweaks,
> is posted here -
> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis
>
> Note that lack of inclusion of your minor tweaks obviously does not mean
> that they've been rejected; I just wanted to complete the process of
> checking in a new branch, doing a pull request, and merging the new branch
> with main.
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.h...@valimail.com
> *p:* 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.
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Todd Herr]

Picking up the thread on another ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

John Levine asserted that there wasn't a lot of strong opinion on the
matter, and therefore we'd be leaving the spec as is, with the MAIL FROM
SPF check the only one that matters for DMARC.

Ale replied, but I don't interpret his reply as challenging John's
assertion.

Can this ticket be closed?

On Thu, Dec 31, 2020 at 9:47 AM Alessandro Vesely  wrote:

> On Wed 30/Dec/2020 22:06:01 +0100 John R Levine wrote:
> >> We would like to close this ticket by Dec 15, two weeks from now, so
> short
> >> trenchant comments are welcome.
> >>
> >> Ticket #1 is about SPF alignment.  We need to replace references to
> 4408 with
> >> 7408, ando clarify what if anything we do with SPF HELO checks if
> >> the MAIL FROM is null.  One possibility is to say only MAIL FROM SPF
> counts,
> >> if you want to align your bounces, sign them.  The other is to
> explicitly say
> >> that HELO alignment is OK on bounces.
> >
> > I didn't hear a lot of strong opinions, but I think they leaned in the
> > direction of only checking the MAIL FROM, since the name of the MTA
> often is
> > unrelated to the From: domain.
> >
> > This means that if you want your bounces to be DMARC aligned, they'd
> need DKIM
> > signatures.
>
>
> Bounces with HELO mta.example.com should have From:
> postmas...@mta.example.com,
> where example.com may be a virtual domain or the "real" domain name,
> depending
> on the configuration.
>
> --

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Todd Herr]

On Tue, Jan 19, 2021 at 2:18 PM Alessandro Vesely  wrote:

> On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote:
> > Concerns were voiced about interoperability impacts for Ale's
> suggestions,
> > and Ale committed to running an experiment to see if there were changes
> to
> > his inbound report flows when he implemented one variant for expressing
> the
> > URI in the rua tag (v=DMARC1; p=none; rua=mailto:lo...@example.com,
> > mailto:report@service.example, OR-https://service.example/report/;), but
> > there have been no subsequent posts by him to the list to report on
> > results.
>
>
> It seems to work perfectly.
>
>
Can you provide more details, please?

Are you receiving reports by HTTPS, or have you not seen any reduction in
reports, or both, or other?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Todd Herr]

It seems that I was not successful in conveying my meaning in a few
statements, so allow me to try again...


On Tue, Jan 19, 2021 at 10:28 AM Hector Santos  wrote:

> On 1/19/2021 9:02 AM, Todd Herr wrote:>
> > Other concerns were raised about privacy and security issues that
> > might be inherent in and unique to adding this kind of functionality,
> > issues that may not have been fully discussed or understood by the
> > community over the years. There was also a question about whether or
> > not this is something that people are asking for.
>
> Reporting concepts were in the each DKIM Policy proposal (SSP, DSAP,
> ADSP) -- a "-r" tag option to send reports. The main concerns were
> unsolicited report abuse.   The DSAP proposal (my own) recognize it
> could be optional so it provided:
>

My mention of "other concerns ... about privacy and security" is in
reference to a post in this thread that Mike Hammer made in early December,
where he wrote:

"I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration."



> > Hatless, it seems to me that the safest implementation of this
> > feature, presuming the security and privacy concerns can be addressed
> > to the satisfaction of those who raised them, would be to add a new
> > tag, as John has proposed, so as to minimize interoperability issues.
> > I say "minimize", rather than "avoid", simply because while RFC 7489
> > says "Unknown tags MUST be ignored.", I don't believe we can say with
> > 100% certainty that all implementations of DMARC policy record parsing
> > in the known world (both by report generators and third parties who
> > advise domains on how to publish DMARC records), implementations that
> > work now, won't "break" if a new tag is introduced. Of course, that'd
> > be their problem, not ours, because they weren't following the
> > existing rules.
>
> We can not continue to design Internet protocols without upward design
> considerations. This is part of the forward and backward compatibility
> design concepts.  Any problem would be a known tag with new
> functionality than originally expected. Sure, we can't say it will not
> happen, but its going to be a very low percentage, if any.  They have
> to fix it.
>
> > As editor, I seek guidance from the working group on how to proceed here.
>
> I am for a URI protocol method as part of the current tag rather than
> a new a separate tag.
>
> However, in principle, I don't see any issue with adding new tags,


I'm sorry, but I'm not clear on what position you're advocating here. You
assert that "any problem would be a known tag with new functionality than
originally expected" (which would seem to argue for using a new tag such as
ruap) but then you state that you're for a URI protocol method as part of
the current tag (which would seem to argue against using ruap, but instead
figuring out a way to add https: to rua), but then you state you don't see
any issue with adding new tags.

Can you help me understand your position better, please?

[snip]


> My point is simple, extended tags MUST be part of the protocol's
> extendability. If there is evidence with 100% sureness there going to
> be a significant compatibility problem with legacy software that can
> not be corrected, then the only option is a new DMARC version 2
> resource record.
>
> I don't think we (I know I can't) can continue with DMARCbis without
> Extended Tag support and be hesitant to invent them because there is a
> compatibility problem.
>
>
I wasn't arguing against adding a new tag, merely being cautious, perhaps
overly so, in refusing to assert with 100% certainty that doing so won't
cause any problems.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely]

On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote:

Concerns were voiced about interoperability impacts for Ale's suggestions,
and Ale committed to running an experiment to see if there were changes to
his inbound report flows when he implemented one variant for expressing the
URI in the rua tag (v=DMARC1; p=none; rua=mailto:lo...@example.com, 
mailto:report@service.example, OR-https://service.example/report/;), but

there have been no subsequent posts by him to the list to report on
results.



It seems to work perfectly.


Best
Ale
--




















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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Hector Santos]

On 1/19/2021 9:02 AM, Todd Herr wrote:>

Other concerns were raised about privacy and security issues that
might be inherent in and unique to adding this kind of functionality,
issues that may not have been fully discussed or understood by the
community over the years. There was also a question about whether or
not this is something that people are asking for.


Reporting concepts were in the each DKIM Policy proposal (SSP, DSAP, 
ADSP) -- a "-r" tag option to send reports. The main concerns were 
unsolicited report abuse.   The DSAP proposal (my own) recognize it 
could be optional so it provided:


   https://tools.ietf.org/html/draft-santos-dkim-dsap-00

   4.5.  DSAP Tag: r=

   This tag is optional.  If not defined, the default is no abuse-
   address is available.

is either the user-part or a FQDN email address to
   optional send abuse reports.

   Examples:
  r=abuse
  r=ab...@example.com

   If only the user-part is defined, then the full address is
   established by using the originating address domain.

   DKIM verifiers have the option to honor or not honor this reporting
   address.  DKIM signers MUST be aware this reporting address may not
   be utilized by verifiers.

   Verifiers should be aware this reporting address can be a source of
   an report attack vector (Section 7.4).  One possible implementation
   considerations would to limit the report to one report only and to
   track the reception and/or response of the reporting.


but the Section 7.4 discussion was TBD.




Hatless, it seems to me that the safest implementation of this
feature, presuming the security and privacy concerns can be addressed
to the satisfaction of those who raised them, would be to add a new
tag, as John has proposed, so as to minimize interoperability issues.
I say "minimize", rather than "avoid", simply because while RFC 7489
says "Unknown tags MUST be ignored.", I don't believe we can say with
100% certainty that all implementations of DMARC policy record parsing
in the known world (both by report generators and third parties who
advise domains on how to publish DMARC records), implementations that
work now, won't "break" if a new tag is introduced. Of course, that'd
be their problem, not ours, because they weren't following the
existing rules.


We can not continue to design Internet protocols without upward design 
considerations. This is part of the forward and backward compatibility 
design concepts.  Any problem would be a known tag with new 
functionality than originally expected. Sure, we can't say it will not 
happen, but its going to be a very low percentage, if any.  They have 
to fix it.



As editor, I seek guidance from the working group on how to proceed here.


I am for a URI protocol method as part of the current tag rather than 
a new a separate tag.


However, in principle, I don't see any issue with adding new tags, in 
fact, I am still here on the basis extended protocols will emerged 
once the base protocol is completed.  ATPS will be available to 
piggyback off the DMARC record as it did off ADSP.  The ATPS protocol 
adds "atps=y" tag to the DMARC record.  We have never received reports 
of issues related to extended tags.


There is a also a small scale version called ASL (Authorized Signer 
List) tag which defines a few domains authorized as resigners; for 
example:


asl=example1.com, example2.com, ietf.org, gmail.com

If you believe that adding a new tag is going to be a problem for 
DMARC, then we might as well come up with a new DKIM Policy model and 
a new resource record lookup name.


Imo, you guys are really missing the boat here.  Extended tags is a 
major part of a DKIM POLICY model future simply because we have not 
yet imagine all the needs to make it work well and integrate with 
other concepts.  In DSAP, for example, we had tags such as:


++
| Description|  DSAP Record Tag  |
||
| Version tag|  v=/  |
||
| Original party signing |  op=  |
| practice   |   |
||
| 3rd party signing  |  3p=  |
| practice   |   |
||
| Authorized List of |  dl=|
| 3rd party domains  |   |
||
| Signature Hashing  |  a=   |
| Method |   |
||
| Reporting address  |  r=|
||
| Note or comment|  n=   

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Tue, Jan 19, 2021 at 4:34 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I raised objections to the definition of "non-existent", which never
> received an adequate response before the discussion went silent.
>
> DMARC checks the From  header address, which may exist only as an
> identifier used for mass mailings.   These mailings are often sent by an
> ESP using an unrelated SMTP address.As such, the From address need not
> be associated with any A, , or MX record.I assert that the only
> viable definition of non-existent is "not registered", as evidenced by
> absence of an NS record.
>

This is a discussion of DMARC, not of PSD, right?  DMARC defines this test
in an Appendix, and then makes it non-mandatory.  PSD says to apply that
test for domains that request it.

Hooking this test up to registration requires introducing RDAP or something
similar.  Is that what we're talking about here?

I don't believe the proposed definition of "non-existent" is reliably true
> even in the special case of interest for this document, impersonation fraud
> occurring at the top of an organizational structure.  Example.PSD may
> legitimately use mail.Example.PSD for email and www.example.psd for web.
>  If the proposed condition MUST always be true, I have not seen that fact
> demonstrated.   Since the document raises a general concern about
> fraudulent use of non-existent domains, the definition used should be one
> that can be generalized.,
>

This sounds like something that should be solved in DMARC, not PSD, but
naturally consensus wins here, so have at it.

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

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Murray S. Kucherawy]

On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely  wrote:

> I guess "[this document]" refers to the RFC number to be.  I think it's
> useless
> and can be safely removed, all of the five occurrences of it.
>

That's fine too.

>> I believe that my strongest critique was that section 1 is difficult to
> >> understand if one does not already understand DMARC, and it does not
> >> seem that the section has been revised.  Re-reading it, I notice that it
> >> says "DMARC leverages public suffix lists to determine which domains are
> >> organizational domains."  [...]
>
> In fact, those are the two terms appearing in the title.  BTW, I'd change
> the
> title to:
>
>  Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
>  Extension For Public Suffix Domains (PSDs)
>
> Anyway, I agree it is correct to introduce /both/ terms.
>

I think that's needlessly verbose.  A compromise:

"Experimental DMARC Extension for Public Suffix Domains"

> To determine the organizational domain for a message under evaluation,
> > and thus where to look for a policy statement, DMARC makes use of a
> > Public Suffix List.
> > The process for doing this can be found in Section 3.2 of the DMARC
> > specification.
>
> Couldn't we skip that kind of functional intro and say something general,
> such
> as anticipating Section 2.2:
>
>  Public Suffix Domains (PSDs) are domain names publicly accessible for
>  domain registration.  As explained in Section 2.2, they include all
> top
>  level domains and some more.  The way delegations occur on the global
>  Internet makes it difficult to establish whether a domain is a PSD.  A
>  community maintained Public Suffix List (PSL) exists for that purpose.
>
> Thinking twice, perhaps we don't need to introduce the PSL until Section
> 3.4.
> In that case, strike the last two sentences of the above paragraph.
>

It's not obvious to me that this is better, but sure, let's discuss it.

> DMARC as specified presumes that domain names present in a PSL are not
> > organizational domains and thus not subject to DMARC processing;
> domains
> > are either organizational domains, sub-domains of organizational
> > domains, or listed on a PSL.  For domains listed in a
> > PSL, i.e., TLDs and domains that exist between TLDs and
> > organization level domains, policy can only be published for the
> > exact domain.
>
> That's still overly specific for an introduction.  It only serves to
> present
> the concept that there are domains that are not actually organizational
> domains
> but are characterized by a sort of organizational flavor.  The "these
> domains"
> of the following sentence.  We don't need seven lines of text for that.
>

This is text in -09, not something I'm adding.  Apparently this context was
valuable before.

>> Looking at the second paragraph of section 1, I notice that despite all
> >> the special terms for classifying domain names in section 2, the example
> >> in this section does not describe which of the domain names that it
> >> mentions fall into which of these classes.  E.g. "tax.gov.example" is
> >> said to be registered, but it looks like it is also the organizational
> >> domain, and "gov.example" is its longest PSD.  It would also help to
> >> mention that "tax.gov.example" is "registered at" "gov.example" to
> >> introduce the details of the usage "registered at".
> >>
> >> Suppose there exists a domain "tax.gov.example" (registered at
> >> "gov.example") ...
> >>
> >
> > Introduce a new Section 1.1: "Example" with this:
>
> I don't fully agree.  The example only lasts until the end of page 3.
> From
> page 4 on, the text describes the core of the experiment, so it shouldn't
> be
> under an "Example" heading.  If we skip the PSL, the example remains quite
> compact even after adding those "registered at".
>

I don't think you read my suggestion correctly.  I proposed a new Section
1.2 to contain the text you're talking about.  You cited it below but
appear to have missed it.

> A suggestion for 2.4:
> >
> > NEW:
> >
> > The longest PSD is the Organizational Domain with one label removed.
> > It names the immediate parent node of the Organizational Domain in the
> > DNS namespace tree.
>
> s/one/the leftmost/
>

Sure.

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Todd Herr]

Picking up the thread on a ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

In reviewing the discussion, I don't believe a consensus has emerged on how
to implement this feature, or even whether to do it.

John proposed a new tag, ruap, for specifying HTTPS URIs (along with mailto:
and supposedly others that may be implemented in the future), while Ale
proposed different ways to express it in the existing rua tag.

Concerns were voiced about interoperability impacts for Ale's suggestions,
and Ale committed to running an experiment to see if there were changes to
his inbound report flows when he implemented one variant for expressing the
URI in the rua tag ( v=DMARC1; p=none; rua=mailto:lo...@example.com,
mailto:report@service.example, OR-https://service.example/report/;), but
there have been no subsequent posts by him to the list to report on results.

Other concerns were raised about privacy and security issues that might be
inherent in and unique to adding this kind of functionality, issues that
may not have been fully discussed or understood by the community over the
years. There was also a question about whether or not this is something
that people are asking for.

Hatless, it seems to me that the safest implementation of this feature,
presuming the security and privacy concerns can be addressed to the
satisfaction of those who raised them, would be to add a new tag, as John
has proposed, so as to minimize interoperability issues. I say "minimize",
rather than "avoid", simply because while RFC 7489 says "Unknown tags MUST
be ignored.", I don't believe we can say with 100% certainty that all
implementations of DMARC policy record parsing in the known world (both by
report generators and third parties who advise domains on how to publish
DMARC records), implementations that work now, won't "break" if a new tag
is introduced. Of course, that'd be their problem, not ours, because they
weren't following the existing rules.

As editor, I seek guidance from the working group on how to proceed here.

On Thu, Dec 31, 2020 at 11:35 AM Alessandro Vesely  wrote:

> On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote:
> > On Thu, 31 Dec 2020, Alessandro Vesely wrote:
> >
> >> On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
> >>> [ add ruap= to allow https in preference to mailto ]
> >>
> >> I still like better sticking to a unique tag (rua=) and applying
> OR-slashes.
> >> With a comma, it is backward compatible:
> >>
> >> v=DMARC1; p=none; rua=mailto:lo...@example.com, mailto:
> report@service.example, /https://service.example/report/;
> >
> > No, it's invalid according to the syntax in RFC 7489.
>
>
> I see.  We have:
>
>  dmarc-auri  = "rua" *WSP "=" *WSP
> dmarc-uri *(*WSP "," *WSP dmarc-uri)
>
>  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>
>  scheme  = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
>
> So /https cannot be a scheme.  How about:
>
>  v=DMARC1; p=none; rua=mailto:lo...@example.com, mailto:
> report@service.example, OR-https://service.example/report/;
>
>
> > We have no idea what existing implementations do with DMARC records with
> syntax errors.
> >
> > Here's an experiment -- put that slash syntax in the rua= in your DMARC
> record
> > and see who does or doesn't continue sending reports.
>
>
> Done, with the second alternative.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Douglas Foster]

I raised objections to the definition of "non-existent", which never
received an adequate response before the discussion went silent.

DMARC checks the From  header address, which may exist only as an
identifier used for mass mailings.   These mailings are often sent by an
ESP using an unrelated SMTP address.As such, the From address need not
be associated with any A, , or MX record.I assert that the only
viable definition of non-existent is "not registered", as evidenced by
absence of an NS record.

I don't believe the proposed definition of "non-existent" is reliably true
even in the special case of interest for this document, impersonation fraud
occurring at the top of an organizational structure.   Example.PSD may
legitimately use mail.Example.PSD for email and www.example.psd for web.
 If the proposed condition MUST always be true, I have not seen that fact
demonstrated.   Since the document raises a general concern about
fraudulent use of non-existent domains, the definition used should be one
that can be generalized.,

Doug Foster

On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy 
wrote:

> In the interests of getting this document on its way, I'd like to suggest
> the following edits in response to Dale's most recent message.  If the
> working group concurs, we can finally get this out to Last Call.
>
> My goal as an AD here is just to get the GenART feedback addressed, but
> the text is being submitted as a WG contribution for discussion and
> consensus consideration, not as a demand.   Please process accordingly; I
> believe the agreement is to do another WGLC on the document before it goes
> on its way, so the sooner consensus is reached on all of this, the sooner
> it goes.
>
> First, a suggestion of my own that I think I saw elsewhere, but it's not
> in Dale's reply: In several places there's a reference to "DMARC
> [RFC7489]".  That's appropriate the first time the reference is made, but I
> think after that you can just say "DMARC" when referring to the protocol
> generally, or to "RFC 7489" when you need to make a specific section or
> text reference.  They don't need to appear together everywhere.
>
> I think Dave's original feedback has been addressed -- good stuff -- so
> here are my suggestions around what's left:
>
> On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley  wrote:
>
>> My apologies for not tending to this promptly.
>>
>> In regard to the description of the experiments, the result criteria are
>> rather subjective, but I don't see that as a problem.  It does seem to
>> me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
>> too narrow, as only the 3rd experiment seems to be about privacy
>> issues.  A title as generic as "PSD DMARC Experiments" would be fine.
>>
>
> That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
> we want to treat it all as one common thing.
>
>
>> Although I note that even the -09 does not define "PSD", only "longest
>> PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
>> equal to "PSO Controlled Domain Name", though, or rather to some related
>> set of them.  That needs to be cleaned up in some way.
>>
>
> PSD appears to be well defined in Section 2.2.
>
> In section 3.5 and later there is the phrase "[this document] longest
>> PSD".  I'm not sure, but I think this is supposed to be "longest PSD
>> ([this document] section NN.NN)".
>>
>
> Agreed.
>
> I believe that my strongest critique was that section 1 is difficult to
>> understand if one does not already understand DMARC, and it does not
>> seem that the section has been revised.  Re-reading it, I notice that it
>> says "DMARC leverages public suffix lists to determine which domains are
>> organizational domains."  Ignoring that I dislike this use of
>> "leverage", a critical point is that it takes the existence of public
>> suffix lists a priori -- indeed, this use of "leverage" generally means
>> that the leveraged thing already exists and one is now extracting
>> additional benefit from that.  Whereas I've never heard of public suffix
>> lists and would naively expect that they are difficult to create and
>> maintain.  It might be better to say "DMARC uses public suffix lists to
>> determine which domains are organizational domains.  Public suffix lists
>> are obtained/maintained/distributed by ..."
>>
>
> Replace all of Section 1 with this (ignore funny line wrapping):
>
>DMARC [RFC7489 ] provides a mechanism 
> for publishing organizational
>policy information to email receivers.  DMARC allows policy to be
>specified for both individual domains and for organizational domains
>and their sub-domains within a single organization.
>
>To determine the organizational domain for a message under evaluation,
>and thus where to look for a policy statement, DMARC makes use of a Public 
> Suffix List.
>The process for doing this can be found in Section 3.2 of the DMARC 

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

[Alessandro Vesely]

On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:

[...]
On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley  wrote:


My apologies for not tending to this promptly.

In regard to the description of the experiments, the result criteria are
rather subjective, but I don't see that as a problem.  It does seem to
me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
too narrow, as only the 3rd experiment seems to be about privacy
issues.  A title as generic as "PSD DMARC Experiments" would be fine.



That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
we want to treat it all as one common thing.



+1



Although I note that even the -09 does not define "PSD", only "longest
PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
equal to "PSO Controlled Domain Name", though, or rather to some related
set of them.  That needs to be cleaned up in some way.



PSD appears to be well defined in Section 2.2.



+1



In section 3.5 and later there is the phrase "[this document] longest

PSD".  I'm not sure, but I think this is supposed to be "longest PSD
([this document] section NN.NN)".



Agreed.



I guess "[this document]" refers to the RFC number to be.  I think it's useless 
and can be safely removed, all of the five occurrences of it.


It is clearer and more useful to specify the referred document when it is /not/ 
this document.  For example:


Changes in Section 6.5 of RFC 7489 "Domain Owner Actions"

The above is going to be rendered with the correct anchor in the htmlized 
version of the document.  It can be expressed in xml as:




so as to generate correct links whenever possible.



I believe that my strongest critique was that section 1 is difficult to
understand if one does not already understand DMARC, and it does not
seem that the section has been revised.  Re-reading it, I notice that it
says "DMARC leverages public suffix lists to determine which domains are
organizational domains."  [...]



In fact, those are the two terms appearing in the title.  BTW, I'd change the 
title to:


Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Extension For Public Suffix Domains (PSDs)

Anyway, I agree it is correct to introduce /both/ terms.



Replace all of Section 1 with this (ignore funny line wrapping):

DMARC [RFC7489 ] provides a
mechanism for publishing organizational
policy information to email receivers.  DMARC allows policy to be
specified for both individual domains and for organizational domains
and their sub-domains within a single organization.



+1 to break the paragraph here.



To determine the organizational domain for a message under evaluation,
and thus where to look for a policy statement, DMARC makes use of a
Public Suffix List.
The process for doing this can be found in Section 3.2 of the DMARC
specification.



Couldn't we skip that kind of functional intro and say something general, such 
as anticipating Section 2.2:


Public Suffix Domains (PSDs) are domain names publicly accessible for
domain registration.  As explained in Section 2.2, they include all top
level domains and some more.  The way delegations occur on the global
Internet makes it difficult to establish whether a domain is a PSD.  A
community maintained Public Suffix List (PSL) exists for that purpose.

Thinking twice, perhaps we don't need to introduce the PSL until Section 3.4. 
In that case, strike the last two sentences of the above paragraph.




DMARC as specified presumes that domain names present in a PSL are not
organizational domains and thus not subject to DMARC processing; domains
are either organizational domains, sub-domains of organizational
domains, or listed on a PSL.  For domains listed in a
PSL, i.e., TLDs and domains that exist between TLDs and
organization level domains, policy can only be published for the
exact domain.



That's still overly specific for an introduction.  It only serves to present 
the concept that there are domains that are not actually organizational domains 
but are characterized by a sort of organizational flavor.  The "these domains" 
of the following sentence.  We don't need seven lines of text for that.




No method is available for these domains to express
policy or receive feedback reporting for sub-domains.  This missing
method allows for the abuse of non-existent organizational-level
domains and prevents identification of domain abuse in email.

This document specifies experimental updates to the DMARC and PSL
algorithm cited above, in an attempt to mitigate this abuse.



If the PSL is not yet introduced:

This document specifies experimental updates to DMARC and its policy
discovery, in an attempt to mitigate this abuse.



Looking at the second paragraph of section 1, I notice that despite all
the special ter