Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Dotzero]

I'm comfortable with the language.

Michael Hammer

On Thu, Feb 18, 2021 at 3:40 PM Brotman, Alex  wrote:

> Aggregated comments:
>
> --
> Aggregate feedback reports contain aggregated data relating to messages
> purportedly originating from the Domain Owner. The data does not contain
> any identifying characteristics about individual users. No personal
> information such as individual email addresses, IP addresses of
> individuals, or the content of any messages, is included in reports.
>
> Mail Receivers should have no concerns in sending reports as they do not
> contain personal information. In all cases, the data within the reports
> relates to the domain-level authentication information provided by mail
> servers sending messages on behalf of the Domain Owner. This information is
> necessary to assist Domain Owners in implementing and maintaining DMARC.
>
> Domain Owners should have no concerns in receiving reports as they do not
> contain personal information. The reports only contain aggregated data
> related to the domain-level authentication details of messages claiming to
> originate from their domain. This information is essential for the proper
> implementation and operation of DMARC. Domain Owners who are unable to
> receive reports for organizational reasons, can choose to exclusively
> direct the reports to an external processor.
> --
>
> Agreeable?
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> > -Original Message-
> > From: dmarc  On Behalf Of Alessandro Vesely
> > Sent: Thursday, February 18, 2021 12:09 PM
> > To: Kurt Andersen (b) ; Ken O'Driscoll
> > 
> > Cc: dmarc@ietf.org; John Levine 
> > Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> >
> > On Thu 18/Feb/2021 17:52:55 +0100 Kurt Andersen (b) wrote:
> > > On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  > > 40wemonitoremail@dmarc.ietf.org> wrote:
> > >
> > >>
> > >> . . . I'd propose something like the below, which I think gets across
> > >> what we all want to say.
> > >>
> > >> ===
> > >> Aggregate feedback reports contain anonymized data relating to
> > >> messages purportedly originating from the Domain Owner. The data does
> > >> not contain any identifying characteristics about individual senders
> > >> or receivers. No personal information such as individual email
> > >> addresses, IP addresses of individuals, or the content of any
> messages, is
> > included in reports.
> > >>
> > >> Mail Receivers should have no concerns in sending reports as they do
> > >> not contain personal information. In all cases, the data within the
> > >> reports relates to the authentication information provided by mail
> > >> servers sending messages on behalf of the Domain Owner. This
> > >> information is necessary to assist Domain Owners in implementing and
> > maintaining DMARC.
> > >>
> > >> Domain Owners should have no concerns in receiving reports as they do
> > >> not contain personal information. The reports only contain aggregated
> > >> anonymized data related to the authentication details of messages
> > >> claiming to originate from their domain. This information is
> > >> essential for the proper implementation and operation of DMARC.
> > >> Domain Owners who are unable to receive reports for organizational
> > >> reasons, can choose to exclusively direct the reports to an external
> > processor.
> > >> ===
> > >>
> > >
> > > With a s/anonymized/aggregated/g change, this seems like reasonable
> > > language. In technical terms, there is no anonymization involved. The
> > > only other issue might be some ambiguity in the intepretation of the
> > > term "individual senders or receivers" because the IP addresses of the
> > > MTAs involved in the email interchange are definitely in the report.
> > > As someone has pointed out earlier in the thread, a compromised home
> > > computer which is able to send out on port 25 would indeed be exposed
> > > in such a scenario, though it is a rare case.
> >
> >
> > I'd s/individual senders or receivers/individual users/.
> >
> > Also s/authentication/domain-level authentication/.
> >
> >
> > Best
> > Ale
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__
> ;!
> > !CQl3mcHX2A!QnQcMsS_KTWtqiiZuaapRUWc3xT1P55tS453rXWzE_lJElYm2DKE3
> > yW2lwFWuJZIJs-sye0H4w$
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Brotman, Alex]

Aggregated comments:

--
Aggregate feedback reports contain aggregated data relating to messages 
purportedly originating from the Domain Owner. The data does not contain any 
identifying characteristics about individual users. No personal information 
such as individual email addresses, IP addresses of individuals, or the content 
of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not 
contain personal information. In all cases, the data within the reports relates 
to the domain-level authentication information provided by mail servers sending 
messages on behalf of the Domain Owner. This information is necessary to assist 
Domain Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not 
contain personal information. The reports only contain aggregated data related 
to the domain-level authentication details of messages claiming to originate 
from their domain. This information is essential for the proper implementation 
and operation of DMARC. Domain Owners who are unable to receive reports for 
organizational reasons, can choose to exclusively direct the reports to an 
external processor.
--

Agreeable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Thursday, February 18, 2021 12:09 PM
> To: Kurt Andersen (b) ; Ken O'Driscoll
> 
> Cc: dmarc@ietf.org; John Levine 
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> On Thu 18/Feb/2021 17:52:55 +0100 Kurt Andersen (b) wrote:
> > On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  > 40wemonitoremail@dmarc.ietf.org> wrote:
> >
> >>
> >> . . . I'd propose something like the below, which I think gets across
> >> what we all want to say.
> >>
> >> ===
> >> Aggregate feedback reports contain anonymized data relating to
> >> messages purportedly originating from the Domain Owner. The data does
> >> not contain any identifying characteristics about individual senders
> >> or receivers. No personal information such as individual email
> >> addresses, IP addresses of individuals, or the content of any messages, is
> included in reports.
> >>
> >> Mail Receivers should have no concerns in sending reports as they do
> >> not contain personal information. In all cases, the data within the
> >> reports relates to the authentication information provided by mail
> >> servers sending messages on behalf of the Domain Owner. This
> >> information is necessary to assist Domain Owners in implementing and
> maintaining DMARC.
> >>
> >> Domain Owners should have no concerns in receiving reports as they do
> >> not contain personal information. The reports only contain aggregated
> >> anonymized data related to the authentication details of messages
> >> claiming to originate from their domain. This information is
> >> essential for the proper implementation and operation of DMARC.
> >> Domain Owners who are unable to receive reports for organizational
> >> reasons, can choose to exclusively direct the reports to an external
> processor.
> >> ===
> >>
> >
> > With a s/anonymized/aggregated/g change, this seems like reasonable
> > language. In technical terms, there is no anonymization involved. The
> > only other issue might be some ambiguity in the intepretation of the
> > term "individual senders or receivers" because the IP addresses of the
> > MTAs involved in the email interchange are definitely in the report.
> > As someone has pointed out earlier in the thread, a compromised home
> > computer which is able to send out on port 25 would indeed be exposed
> > in such a scenario, though it is a rare case.
>
>
> I'd s/individual senders or receivers/individual users/.
>
> Also s/authentication/domain-level authentication/.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!QnQcMsS_KTWtqiiZuaapRUWc3xT1P55tS453rXWzE_lJElYm2DKE3
> yW2lwFWuJZIJs-sye0H4w$

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

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting 
& Conformance WG of the IETF.

Title   : Domain-based Message Authentication, Reporting, and 
Conformance (DMARC) Failure Reporting
Authors : Steven M Jones
  Alessandro Vesely
Filename: draft-ietf-dmarc-failure-reporting-01.txt
Pages   : 11
Date: 2021-02-18

Abstract:
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) is a scalable mechanism by which a domain owner can request
   feedback about email messages using their domain in the From: address
   field.  This document describes "failure reports," or "failed message
   reports," which provide details about individual messages that failed
   to authenticate according to the DMARC mechanism.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-failure-reporting-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt

[Murray S. Kucherawy]

Circling back to this:

On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker  wrote:

> On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote:
>
> On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker  wrote:
>
>>
>> Abstract
>>
>>DMARC (Domain-based Message Authentication, Reporting, and
>>Conformance) is a scalable mechanism by which a mail-originating
>>organization can express domain-level policies and preferences for
>>message validation, disposition, and reporting, that a mail-receiving
>>organization can use to improve mail handling.  The design of DMARC
>>presumes that domain names represent either nodes in the tree below
>>which registrations occur, or nodes where registrations have
>>
>> DMARC does not have 'registrations'.
>>
>
> It's referring to domain name registrations, not DMARC registrations.
>
> Also the occur/occured contrast has no obvious meaning to me.  Really, I
>> have no idea what's intended by it.
>>
> "exist"?
> "take place"?
> "are made"?
> "are done"?
>
> The issue wasn't synonyms but semantics.  'registrations occurred' has no
> obvious DMARC meaning.
>
> unless, perhaps, the meaning is 'domain names exist', but that still
> doesn't explain the contrast being drawn.
>
I'm struggling to understand the concern here.  I think we all know what it
means to register a domain, and that the namespace is arranged as a tree,
and that trees are made up of nodes, and that some nodes are above the cut
where registrations take place while the rest are below.  What other
meaning might someone in this space infer from this text?

Maybe this is better, just for the sake of having something else to look at?

   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent nodes in the DNS tree that are either
   reserved as points below which new domain name registrations are made, or are
   the results of those registrations; it does not permit a node to
have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

Apart from that, I'm at a loss to understand what's confusing.  I'm not
convinced that "registrations" in the context of domain names is unclear to
a reader familiar with this space.

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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Alessandro Vesely]

On Thu 18/Feb/2021 17:52:55 +0100 Kurt Andersen (b) wrote:

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  wrote:



. . . I'd propose something like the below, which I think gets across what
we all want to say.

===
Aggregate feedback reports contain anonymized data relating to messages
purportedly originating from the Domain Owner. The data does not contain
any identifying characteristics about individual senders or receivers. No
personal information such as individual email addresses, IP addresses of
individuals, or the content of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not
contain personal information. In all cases, the data within the reports
relates to the authentication information provided by mail servers sending
messages on behalf of the Domain Owner. This information is necessary to
assist Domain Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not
contain personal information. The reports only contain aggregated
anonymized data related to the authentication details of messages claiming
to originate from their domain. This information is essential for the
proper implementation and operation of DMARC. Domain Owners who are unable
to receive reports for organizational reasons, can choose to exclusively
direct the reports to an external processor.
===



With a s/anonymized/aggregated/g change, this seems like reasonable
language. In technical terms, there is no anonymization involved. The only
other issue might be some ambiguity in the intepretation of the term
"individual senders or receivers" because the IP addresses of the MTAs
involved in the email interchange are definitely in the report. As someone
has pointed out earlier in the thread, a compromised home computer which is
able to send out on port 25 would indeed be exposed in such a scenario,
though it is a rare case.



I'd s/individual senders or receivers/individual users/.

Also s/authentication/domain-level authentication/.


Best
Ale
--
















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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Kurt Andersen (b)]

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  wrote:

>
> . . . I'd propose something like the below, which I think gets across what
> we all want to say.
>
> ===
> Aggregate feedback reports contain anonymized data relating to messages
> purportedly originating from the Domain Owner. The data does not contain
> any identifying characteristics about individual senders or receivers. No
> personal information such as individual email addresses, IP addresses of
> individuals, or the content of any messages, is included in reports.
>
> Mail Receivers should have no concerns in sending reports as they do not
> contain personal information. In all cases, the data within the reports
> relates to the authentication information provided by mail servers sending
> messages on behalf of the Domain Owner. This information is necessary to
> assist Domain Owners in implementing and maintaining DMARC.
>
> Domain Owners should have no concerns in receiving reports as they do not
> contain personal information. The reports only contain aggregated
> anonymized data related to the authentication details of messages claiming
> to originate from their domain. This information is essential for the
> proper implementation and operation of DMARC. Domain Owners who are unable
> to receive reports for organizational reasons, can choose to exclusively
> direct the reports to an external processor.
> ===
>

With a s/anonymized/aggregated/g change, this seems like reasonable
language. In technical terms, there is no anonymization involved. The only
other issue might be some ambiguity in the intepretation of the term
"individual senders or receivers" because the IP addresses of the MTAs
involved in the email interchange are definitely in the report. As someone
has pointed out earlier in the thread, a compromised home computer which is
able to send out on port 25 would indeed be exposed in such a scenario,
though it is a rare case.

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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Ken O'Driscoll]

The concern is that PII is contained in the aggregate reports.

The machinations of the individual Information Governance functions that draw 
such conclusions or the decision making processes of individual organisations 
around those conclusions, is not relevant, and won’t help close this ticket.

Ken.

From: dmarc  On Behalf Of Douglas Foster
Sent: Thursday 18 February 2021 02:21
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

It would help me if you could elaborate on the concerns that you have 
encountered.

Which data is sensitive and therefore needing classification?

Which roles creates the objection?   Server owner sending reports, recipient 
domain allowing the server owner to send reports from recipient data, or only 
report recipient?

When the report recipient domain delegates reception to an authorized agent, 
how does the organization making the delegation escape liability for how the 
information is handled and used?


On Wed, Feb 17, 2021 at 4:27 PM Ken O'Driscoll 
mailto:40wemonitoremail@dmarc.ietf.org>>
 wrote:

I PM deployments for organisations and the concept of aggregate reports have 
caused problem more than once. Similar to the PII concerns of providers which 
originated this ticket, these organisations operate in heavily a regulated 
industry and have extensive DPO functions. To give a flavour of what those 
concerns translate to - I have been asked is it possible to implement DMARC 
without using reports! I have also had con-calls about training a new hire to 
read and classify the reports! That's just two examples. It's mostly driven by 
overzealous DPOs but I understand their concerns on some level. When they 
realise that we can distil the report data and it doesn't need to be on-site, 
they hand wave away any custodian concerns and the project moves forward.

So, assuming that my DMARC clients aren't unique, I'm wondering if this section 
could be split into two parts, one for Mail Receivers and one for Domain Owners?

If so, for Domain Owners, I'd propose something like this:

Aggregate feedback reports are essential for the proper implementation and 
operation of DMARC. Domain Owners can choose to exclusively direct reports to a 
processor external to their organization. In such cases, the content of the 
reports are never sent directly to the Domain Owner.

Thoughts?

Ken.

> -Original Message-
> From: dmarc mailto:dmarc-boun...@ietf.org>> On Behalf 
> Of Brotman, Alex
> Sent: Wednesday 17 February 2021 18:40
> To: Alessandro Vesely mailto:ves...@tana.it>>; 
> dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> Incorporating some feedback:
>
> ---
> ## Data Contained Within Reports (Tkt64)
>
> Within the reports is contained an aggregated body of anonymized data
> pertaining to the sending domain.  The data is meant to aid the report
> processors and domain holders in verifying sources of messages
> pertaining to the DMARC Identifier.  The data should not contain any
> identifying characteristics about individual senders or receivers.  An
> entity sending reports should not be concerned with the data contained
> as it does not contain personal information, such as email addresses or
> usernames. There are typically three situations where data is reported
> to the aggregate receivers: messages properly authenticated, messages
> that fail to authenticate as the domain, or messages utilizing the DMARC
> Identifier that have no authentication at all.  In each of these cases,
> there exists no identifying information for individuals, and all content
> within the reports should be related to SMTP servers sending messages
> posing as that domain.
> ---
>
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
>
> > -Original Message-
> > From: dmarc mailto:dmarc-boun...@ietf.org>> On 
> > Behalf Of Alessandro Vesely
> > Sent: Monday, February 15, 2021 8:31 AM
> > To: dmarc@ietf.org
> > Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> >
> > On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> > > Hello folks,
> > >
> > > In ticket #64
> >
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64_
> _;!
> > !CQl3mcHX2A!W97hZ0-
> > iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMRa
> > BuxGQg$ ), it was suggested that a Privacy Considerations section may
> > alleviate some concerns about the ownership of the data.  I created an
> > initial attempt, and thought to get some feedback.  I didn't think we
> > should go too far in depth, or raise corner cases.  Felt like doing so
> > could lead down a rabbit hole of trying to cover all cases. This would
> > go within a "Privacy Considerations" section.
> > >
> > > * Data Contained Within Reports (#64)
> > >
> > > Within the 

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Ken O'Driscoll]

In hindsight, it looks a bit strange to have the first paragraph say "don't 
worry about PII" and the next paragraph say "if you're worried about PII, 
here's how to mitigate".

But it's a genuine concern (misguided or not) and I've been in enough meetings 
to at least understand where it comes from, even if I don't agree. So I'd 
propose something like the below, which I think gets across what we all want to 
say.

===
Aggregate feedback reports contain anonymized data relating to messages 
purportedly originating from the Domain Owner. The data does not contain any 
identifying characteristics about individual senders or receivers. No personal 
information such as individual email addresses, IP addresses of individuals, or 
the content of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not 
contain personal information. In all cases, the data within the reports relates 
to the authentication information provided by mail servers sending messages on 
behalf of the Domain Owner. This information is necessary to assist Domain 
Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not 
contain personal information. The reports only contain aggregated anonymized 
data related to the authentication details of messages claiming to originate 
from their domain. This information is essential for the proper implementation 
and operation of DMARC. Domain Owners who are unable to receive reports for 
organizational reasons, can choose to exclusively direct the reports to an 
external processor.
===

And, I agree - it's a bit weird to be okay with having a policy to not see your 
own reports. But the "see no evil, hear no evil" risk mitigation strategy is 
tried and tested. The whole IG/DPO space is really crazy in some places too.

Ken.

> -Original Message-
> From: John Levine 
> Sent: Thursday 18 February 2021 02:46
> To: dmarc@ietf.org
> Cc: Ken O'Driscoll 
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
> 
> In article
>  angelabs.com> you write:
> >Aggregate feedback reports are essential for the proper implementation
> >and operation of DMARC. Domain Owners can choose to exclusively direct
> >reports to a processor external to their organization. In such cases,
> the content of the reports are never sent directly to the Domain Owner.
> 
> That is OK but I would also want to point out that the data are
> aggregated and contain no individual e-mail addresses of senders or
> recipients, nor IP addresses of individuals nor any contents of
> messages, so it is unlikely that they contain any PII.
> 
> I have to say it seems weird to me that it's OK to send whatever to
> external places but not to your own staff.
> 
> R's,
> John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc