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

[Scott Kitterman <[e-mail]>]

On Wednesday, August 17, 2022 11:12:32 AM EDT John Levine wrote:
> It appears that Alessandro Vesely  <[e-mail]> said:
> >> There is also an HTML version available at:
> >> https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-04.htm
> >> l
> >
> >This version requires some revision/ discussion by the WG.
> >
> >In particular, IANA considerations has two subsections which may neew the
> >chairs approval.
> 
> I see no need to invent new IANA registries and oppose the proposed
> registries.
> 
> It redefines the SPF-DNS report item defined in RFC 6591 in a way that is
> neither forward nor backward compatible.  I oppose this change.
> 
> >The concept of debug messages might be dropped or expanded.
> 
> I see no basis for this change either,

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.

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.

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.  I don't think it's 
appropriate to specify only sending debugging messages when there's no 
mechanism for identifying such messages.  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.

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

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.

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.

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

Scott K