Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
On 3/17/2018 2:41 AM, Kurt Andersen (b) wrote: There are two aspects to this - 1. batching (lightens the load for reporting receivers), and 2. re privacy - the fact that someone with authority (over the domain) has requested said reports suffices for GDPR legal/consent coverage I'll suggest that 'privacy' divides into at least three important distinctions: 1. Identification of PII among a set of data ii ie, define an attribute set 2. Ability to handle PII differentially 3. Policies for deciding when/how to divulge PII and to whom The first two are technical details that seem to make sense for this group. The last does not. The essential benefit of excluding the third item, is that it then means the group does not need legal expertise (except to make sure that the mechanical listing of attributes considered PII is sufficient -- but I'm guessing that's far easier than the when/how/who disclosure behavior d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
Formal opinions would be helpful for people who feel the need for air cover :-) --Kurt On Sat, Mar 17, 2018 at 11:11 AM, Ian Levy wrote: > >- re privacy - the fact that someone with authority (over the domain) >has requested said reports suffices for GDPR legal/consent coverage > > IANAL, but that’s my understanding as well. If it would be helpful, I can > get a formal legal opinion and a statement from the UK Information > Commissioner’s Office. > > > > Ta. > > > > I. > > > > -- > > Dr Ian Levy > > Technical Director > > National Cyber Security Centre > > > > Staff Officer : Kate Atkins, kat...@ncsc.gov.uk > > > > *From:* dmarc *On Behalf Of *Kurt Andersen (b) > *Sent:* 17 March 2018 09:41 > *To:* Steven M Jones > *Cc:* dmarc@ietf.org > *Subject:* Re: [dmarc-ietf] Agenda for IETF 101 DMARC session > > > > On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones wrote: > > On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: > > > >- Creating a diagnostic report that would have some additional >information (such as sending address) and URLs without going quite as far >as a forensic report - so something between the aggregate and forensic >levels > > > I'm probably missing something, but -- aren't email addresses usually > classed as PII in the EU, whether they're sending or receiving at the > moment? Seems to me it would run afoul of the privacy regs that tend to > rule out forensic reports in certain jurisdictions... > > Maybe there's a batch/aggregate angle vs. per-message that helps avoid > that concern? Would time and URLs alone be useful enough to warrant the > effort and expense? > > > > There are two aspects to this - > >1. batching (lightens the load for reporting receivers), and >2. re privacy - the fact that someone with authority (over the domain) >has requested said reports suffices for GDPR legal/consent coverage > > --Kurt > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
* re privacy - the fact that someone with authority (over the domain) has requested said reports suffices for GDPR legal/consent coverage IANAL, but that’s my understanding as well. If it would be helpful, I can get a formal legal opinion and a statement from the UK Information Commissioner’s Office. Ta. I. -- Dr Ian Levy Technical Director National Cyber Security Centre Staff Officer : Kate Atkins, kat...@ncsc.gov.uk<mailto:kat...@ncsc.gov.uk> From: dmarc On Behalf Of Kurt Andersen (b) Sent: 17 March 2018 09:41 To: Steven M Jones Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Agenda for IETF 101 DMARC session On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones mailto:s...@crash.com>> wrote: On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: * Creating a diagnostic report that would have some additional information (such as sending address) and URLs without going quite as far as a forensic report - so something between the aggregate and forensic levels I'm probably missing something, but -- aren't email addresses usually classed as PII in the EU, whether they're sending or receiving at the moment? Seems to me it would run afoul of the privacy regs that tend to rule out forensic reports in certain jurisdictions... Maybe there's a batch/aggregate angle vs. per-message that helps avoid that concern? Would time and URLs alone be useful enough to warrant the effort and expense? There are two aspects to this - 1. batching (lightens the load for reporting receivers), and 2. re privacy - the fact that someone with authority (over the domain) has requested said reports suffices for GDPR legal/consent coverage --Kurt This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfo...@ncsc.gov.uk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones wrote: > On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: > > >- Creating a diagnostic report that would have some additional >information (such as sending address) and URLs without going quite as far >as a forensic report - so something between the aggregate and forensic >levels > > > I'm probably missing something, but -- aren't email addresses usually > classed as PII in the EU, whether they're sending or receiving at the > moment? Seems to me it would run afoul of the privacy regs that tend to > rule out forensic reports in certain jurisdictions... > > Maybe there's a batch/aggregate angle vs. per-message that helps avoid > that concern? Would time and URLs alone be useful enough to warrant the > effort and expense? > There are two aspects to this - 1. batching (lightens the load for reporting receivers), and 2. re privacy - the fact that someone with authority (over the domain) has requested said reports suffices for GDPR legal/consent coverage --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
On 16-03-18 10:47, Steven M Jones wrote: On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: Two more items for discussion (coming from a chat that I had with some of the NCSC folks today): Thanks for sharing their input. * Creating a diagnostic report that would have some additional information (such as sending address) and URLs without going quite as far as a forensic report - so something between the aggregate and forensic levels I'm probably missing something, but -- aren't email addresses usually classed as PII in the EU, whether they're sending or receiving at the moment? Seems to me it would run afoul of the privacy regs that tend to rule out forensic reports in certain jurisdictions... Maybe there's a batch/aggregate angle vs. per-message that helps avoid that concern? Would time and URLs alone be useful enough to warrant the effort and expense? Well, given the upcoming GDPR legislation and the sanctions that comes with it [1], maybe an agenda item 'DMARC reports and privacy' would be a good point. Ideally we would like to have someone present with both GDPR and DMARC knowledge... /rolf [1] https://www.itgovernance.co.uk/dpa-and-gdpr-penalties ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
On 3/15/18 10:19 AM, Kurt Andersen (b) wrote: > Two more items for discussion (coming from a chat that I had with some > of the NCSC folks today): Thanks for sharing their input. > * Creating a diagnostic report that would have some additional > information (such as sending address) and URLs without going quite > as far as a forensic report - so something between the aggregate > and forensic levels > I'm probably missing something, but -- aren't email addresses usually classed as PII in the EU, whether they're sending or receiving at the moment? Seems to me it would run afoul of the privacy regs that tend to rule out forensic reports in certain jurisdictions... Maybe there's a batch/aggregate angle vs. per-message that helps avoid that concern? Would time and URLs alone be useful enough to warrant the effort and expense? --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
Two more items for discussion (coming from a chat that I had with some of the NCSC folks today): 1. Recommendations for protecting against abuse of last-level public domains (such as gov.uk) and first-level NXDOMAIN org domains ( junk.gov.uk) 2. Creating a diagnostic report that would have some additional information (such as sending address) and URLs without going quite as far as a forensic report - so something between the aggregate and forensic levels --Kurt On Sun, Mar 11, 2018 at 1:02 PM, Barry Leiba wrote: > I have uploaded a preliminary session agenda here: > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-dmarc > > If anyone has adjustments to propose, including any specific items to > add to the "next steps" discussion, please post here. > > Barry > > ___ > 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] Agenda for IETF 101 DMARC session
>> 18:15 25 min Next steps, including: >> - draft-akagiri-dmarc-virtual-verification > > That's quite a long time to discuss something that isn't really dmarc. Not all 25 minutes are for that; that is included in the time slot, along with anything else we put into "next steps". (And I'm expecting that we'll wind up with more than 25 minutes, in the end.) > My impression is that after ARC, the industry interest is in finding a path > that standardizes DMARC. This proposal does not serve that goal. We can certainly discuss whether we should consider the virtual-verification proposal at all; please do that on that thread. Very much, please do. I do expect that we'll discuss "path toward a Proposed Standard version of DMARC," and I'll put that into the "next steps" section on the next update to the agenda. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
On 3/11/2018 5:02 AM, Barry Leiba wrote: I have uploaded a preliminary session agenda here: https://datatracker.ietf.org/meeting/101/materials/agenda-101-dmarc the agenda shows: > 18:15 25 min Next steps, including: - draft-akagiri-dmarc-virtual-verification That's quite a long time to discuss something that isn't really dmarc. DMARC introduces the alignment construct, publication of a policy record, and a reporting mechanism. The proposal is to take note of alignment, independent of whether the domain owner has published a policy about it. Having a report take note of validated alignment well might be worth doing, but it's not DMARC. My impression is that after ARC, the industry interest is in finding a path that standardizes DMARC. This proposal does not serve that goal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
Seems like we might want to discuss specific steps toward the next milestone per our charter. I think that ARC is a method of "support[ing] indirect mail flows" but we haven't even discussed the other brainstorm ideas that were tossed into the charter (listed below). Are all of these items necessary to get DMARC put onto a standards track or were they just ideas floated at the time DMARC-WG was chartered so that we'd have some things to discuss? --Kurt (part of 2) Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. and the corresponding work items: Phase II: - Specification of DMARC improvements to support indirect mail flows - Draft Guide on DMARC Usage Phase III: - Review and refinement of the DMARC specification - Completion of Guide on DMARC Usage On Sun, Mar 11, 2018 at 5:02 AM, Barry Leiba wrote: > I have uploaded a preliminary session agenda here: > > https://datatracker.ietf.org/meeting/101/materials/agenda-101-dmarc > > If anyone has adjustments to propose, including any specific items to > add to the "next steps" discussion, please post here. > > Barry > > ___ > 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
