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

[Todd Herr <[e-mail]>]

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 <hsantos=
[e-mail]> 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:* [e-mail]
*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.