Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-04.txt

[Alessandro Vesely <[e-mail]>]

On Thu 18/Aug/2022 17:08:07 +0200 Scott Kitterman wrote:
> 
> I have similar concerns.  Thoughts on the changes in this revision:
> 
> I think adding the reference to Section 3.2 about external destination
> verification is good.
> 
> RFC 9091 says, "PSD DMARC feedback MUST be limited to Aggregate Reports."  I
> think that should be carried forward and so the SHOULD NOT consider RUF= tags
> should be MUST NOT and the bit after the comma (unless there are ...) needs to
> be deleted.


Done on Github copy.


> I agree that 'aggregation techniques' should be changed since there's no
> aggregation involved.  I don't love 'pruning', but I think it's better.


Better terms?


> I think the changes in the techniques list is problematic.  I don't see why
> sending a report to only the first recipient was dropped.


There is a paragraph a few lines above saying:

    Where multiple URIs are selected to receive failure reports, the
    report generator MUST make an attempt to deliver to each of them.

Isn't that the opposite of doing only the first recipient?  A generator cannot 
do both, unless it has a method to detect DDoS.


> I don't think it's appropriate to specify only sending debugging messages
> when there's no mechanism for identifying such messages.

Agreed.  I was thinking something like Subject: [DEBUG] ...  I'd drop that line 
if we're not willing to specify a mechanism.


> In any case, that's more of a privacy risk mitigation strategy than a denial
> of service mitigation. > Generally for denial of service mitigation during normal operations, debugging
> would be one of the first things to go.


Yes, but it's still a pruning technique, no?


> In 3.1 (1) I do not agree with the change to only require DKIM/SPF related
> fields on failure instead of when the message was signed by DKIM or has an SPF
> result.  In the case of partial failures, the information is useful.


None of the failures I received quotes my SPF record.  Albeit SPF actually 
failed, they only report dmarc failure (Auth-Failure: dmarc).  The spec 
suggests a generator can independently issue an SPF failure report.  Similar 
argument for DKIM.

I don't think we can convince those generators to include more data.  I'd 
rather accept current practices.


> Additionally, the limitation to aligned failures further excludes useful
> information.  The change in 3.1 (2) is also problematic as it is predicated on
> the changes in 3.1 (1).


That change was for clarity.  What does it mean "to produce an alignment"?  Did 
it fail or succeed?  Reporting both doesn't say much, it would always be spf, 
dkim, without telling which one verified or failed.


> I think redefining SPF-DNS is a horrible idea.  I agree that, in theory, the
> txt/spf distinction is no longer needed, this would complicate receive
> processing substantially (would need to be able to distinguish between the to
> field formats and to process both) for the very negligible benefit of saving a
> few bits on the wire.


Yes, I removed it in the Github copy.


> I think the 3.2 change to more fully describe the conditions for the external
> destination verification method is a good one.
> 
> For IANA considerations, I think updating the reference for Identity-Alignment
> to this document is correct.  I don't understand the need for a new
> Authentication Failure Types registry.  To the extent it may be a good idea, I
> think this is the wrong place to do it.  This kind of issue should be
> addressed by any RFC6591bis effort that may be done at some point in the
> future.


Having a place where all values are listed is somewhat practical, and may help 
making ARF less of a mess than it is.  I don't know if the bang is worth the buck.


> Related to the failure reporting discussion for PSDs above, the Privacy
> Considerations section of this draft needs to document the information leakage
> potential associated with failure reporting based on PSD records (which is why
> it needs to be a MUST NOT).


Should I add RFC6973 as an informative reference?



Best
Ale
--