Subject: [dmarc-ietf] Agenda for IETF 101 DMARC session

From: Barry Leiba <[email-masked]>
Date: Sun, 11 Mar 2018 08:02:42 -0400

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 12 Mar 2018 16:03:19 -0700

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 <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Mar 2018 16:47:16 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 12 Mar 2018 21:57:41 -0400

> 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

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 12 Mar 2018 23:10:02 -0400

>>  - draft-akagiri-dmarc-virtual-verification
[...]
> 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.

Not all of these points will apply to the WG (or the IETF for that matter), and I've already responded in the thread about the draft, but, for the sake of concision, the central questions seem to me:

1)  Is this DMARC?
2)  If it isn't, should it still be in an RFC?
3)  If it shouldn't be in an RFC, is it nevertheless of use to implementors?

Based on what you and other people have said, I would think the WG should first achieve consensus on question 1, regardless of whether the draft is part of the meeting or not.

Thanks,
Stan

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Mar 2018 06:42:43 -0700

> along with anything else we put into "next steps".
...
> the next update to the agenda.

I suggest broaching this topic here and now, so the agenda entry can 
show something other than an off-charter draft.

To prime that pump...

>    Phase II:
> 
>       Specification of DMARC improvements to support indirect
> mail flows

1.  Besides ARC, are there other wg efforts that should be pursued to 
satisfy this?

    ARC targets intermediary action in mail that originated with a 
DMARC-satisfying configuration.  ARC does not attend to mail that starts 
without that.  That is, mail starting from an independent third party 
source, such as a kiosk.

>       Draft Guide on DMARC Usage

Current version is -04, so this charter item appears to be satisfied.

>    Phase III:
> 
>       Review and refinement of the DMARC specification

Is there technical work on the base specification that would improve it?

      One would be a spec revision to deal with ARC.  Does DMARC still 
'fail'?  Yet the whole point of ARC is to create the possibility of 
still getting delivered, in spite of this.

     And from a note I posted last August:  "BTW, the DMARC spec uses 
the terms 'pass' and 'fail' with respect to the underlying 
authentication mechanisms of DKIM and SPF. It also uses it within the 
context of DMARC processing, itself, but it does not define what those 
terms mean, in that context.  Beyond reference to DMARC 'policy' 
records, text in the specs that talk about processing DMARC policy is 
similarly implicit, rather than explicit. The only clear, explicit 
directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy."

>       Completion of Guide on DMARC Usage

What will it take to complete this doc?

      One example would be a spec revision effort that targets 
clarification, based on experience coding and deploying DMARC.

      I'll also suggest that it would help allay public concerns about 
DMARC to be able to have this document include experience-based text 
about ARC usage; both discussing how to use it and how effective it is.

d/

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 13 Mar 2018 11:32:00 -0400

> show something other than an off-charter draft.

Wise choice. +1

> DMARC-satisfying configuration.  ARC does not attend to mail that 
> starts without that.  That is, mail starting from an independent third 
> party source, such as a kiosk.
>
>

My position on this is that the decision by a validator/mailbox provider 
to use ARC and accept mail that would otherwise fail DMARC falls under 
the heading of "local policy". There does not need to be a spec revision 
to deal with ARC from this perspective. A sending domain publishing a 
DMARC policy is expressing it's wishes, not making demands (it cannot 
enforce). This is true with respect to any local policy a 
validator/mailbox provider implements.

> directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply 

I need to think on this a bit more and go re-read the spec before 
formulating a response.

> about ARC usage; both discussing how to use it and how effective it is.

If this is the case, I would suggest renaming the document to "Guide on 
DMARC and ARC Usage" rather than the original title.

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 13 Mar 2018 18:44:39 -0400

>>
>>      One would be a spec revision to deal with ARC.  Does DMARC
>> still 'fail'?  Yet the whole point of ARC is to create the
>> possibility of still getting delivered, in spite of this.
>
> My position on this is that the decision by a validator/mailbox
> provider to use ARC and accept mail that would otherwise fail DMARC
> falls under the heading of "local policy". There does not need to be a
> spec revision to deal with ARC from this perspective. A sending domain
> publishing a DMARC policy is expressing it's wishes, not making
> demands (it cannot enforce). This is true with respect to any local
> policy a validator/mailbox provider implements.
>

If a domain publishes a "p=reject/quarantine" (restrictive policy), 
the published intent and expectation is to reject or quarantine 
failures.   If the receiver wishes to further relax how it handles 
failures, that would be a specific local policy, not "general policy." 
  Overall, the protocol intent is to Reject/Quarantine.

The ARC question is how does ARC change this existing 
"psuedo-standard" protocol logic?

I prefer an explicit DMARC extended tag (or a author domain ARC seal) 
that publishes the domain intent to use ARC to relax "some" 
p=reject/quarantine failure in some fashion which is not defined at 
the moment.  The preference is to remove/reduce receiver ambiguity of 
what is to be expected when DKIM/DMARC is augmented with the ARC.

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Wed, 14 Mar 2018 21:37:23 +0000

> what is to be expected when DKIM/DMARC is augmented with the ARC.

I still object to this concept on the same basis as the last two times we
had this discussion.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Wed, 14 Mar 2018 21:38:01 +0000

---

From: Hector Santos <[email-masked]>
Date: Wed, 14 Mar 2018 18:02:19 -0400

On 3/14/2018 5:37 PM, Brandon Long wrote:

> On Tue, Mar 13, 2018 at 3:44 PM Hector Santos <[email-masked]

> I still object to this concept on the same basis as the last two times
> we had this discussion.
>
> Brandon

Brandon,

Quite possible you haven't been clear in your DKIM Policy Modeling 
engineering reasoning.

The concept has been written across multiple RFCs since DKIM Policy 
Modeling architecture, including SPF.

If a domain publishes a DNS-based Public Record policy, you SHOULD 
honor its wishes as defined by the protocol recommendations.

You can do what you please with Local policy,  you can even prepare 
your product in the market place (if any) to behave as you want. 
Other implementations can do the same product designs that follow 
closely with the specifications.  That is what the system 
cooperatively competitive. Both SPF and DKIM POLICY docs have been 
very clear a,long these lines and its the #1 reason why we are still 
here after 10+ years trying to resolve same original  "indirect" 
rejection issues, are we not?  First it was SSP, then it was ASDP and 
now its these issues with DMARC.

So if you backing off and are advocating that receivers should ignore 
or add a "Don't really Mean it" rejection semantic regarding Hard Fail 
Policies, with SPF or DMARC, then you need to change the 
specifications and make it more clear in the new specs.

But I suspect a top marketing, security interest, the highest payoff, 
will continue to be to seek and support hard deterministic protocols. 
   That doesn't stop us  from working on new stuff that deal with the 
fuzzy non-deterministic classification decisions. We add some learning 
to it if you want.  Just make it very clear in your DKIM ARC 
augmentation what you want.  If you want ARC to change how DMARC 
words, then you have to say so in your specs.  You just can't assume 
people will blindly ignore what is already in place.

Thanks

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Thu, 15 Mar 2018 10:01:00 -0400

> Is there technical work on the base specification that would improve it?

The bug tracker contains a few items around clarification, removing ambiguity, correcting minor mistakes. Nothing major.

I was expecting someone to come up with a new tag that defined a mechanism for exception querying. EG, I have a piece of email that falls under a DMARC record where the Domain Owner is telling me I can query some resource to figure out if the identifier combination is OK. Aside from hallway conversation, haven't seen anything like it yet.

> What will it take to complete this doc?

Focus & cycles. The document is meant for future implementors. There has been *some* leg work done to collect information. There was talk of rechartering to remove this deliverable, but I hope that has been addressed.

=- Tim

> 
>     One example would be a spec revision effort that targets clarification, based on experience coding and deploying DMARC.
> 
> 
>     I'll also suggest that it would help allay public concerns about DMARC to be able to have this document include experience-based text about ARC usage; both discussing how to use it and how effective it is.
> 
> d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Mar 2018 08:02:13 -0700

On 3/15/2018 7:01 AM, Tim Draegen wrote:
> On Mar 13, 2018, at 9:42 AM, Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>>>   Phase III:
> The bug tracker contains a few items around clarification, removing 
> ambiguity, correcting minor mistakes. Nothing major.
> 
> I was expecting someone to come up with a new tag that defined a 
> mechanism for exception querying. EG, I have a piece of email that falls 
> under a DMARC record where the Domain Owner is telling me I can query 
> some resource to figure out if the identifier combination is OK. Aside 
> from hallway conversation, haven't seen anything like it yet.

Hmmm.  Could you describe this in a bit more detail?  Not an actual 
spec, but to give more of a sense of what it could do and why it would 
be helpful (ie, what current problem it alleviates)?

d/

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 15 Mar 2018 18:19:23 +0100

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

---

From: Steven M Jones <[email-masked]>
Date: Fri, 16 Mar 2018 02:47:57 -0700

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.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 16 Mar 2018 12:11:41 +0100

On 16-03-18 10:47, Steven M Jones wrote:
>> Two more items for discussion (coming from a chat that I had with 
>> some of the NCSC folks today):
>
>>     information (such as sending address) and URLs without going
>>     quite as far as a forensic report - so something between the
>>     aggregate and forensic levels
>>
>
> 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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 17 Mar 2018 10:41:18 +0100

On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones <[email-masked]> wrote:

>    - Creating a diagnostic report that would have some additional

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

---

From: Ian Levy <[email-masked]>
Date: Sat, 17 Mar 2018 10:11:52 +0000

*   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, [email-masked]<mailto:[email-masked]>

From: dmarc <[email-masked]> On Behalf Of Kurt Andersen (b)
Sent: 17 March 2018 09:41
To: Steven M Jones <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Agenda for IETF 101 DMARC session

On Fri, Mar 16, 2018 at 10:47 AM, Steven M Jones <[email-masked]<mailto:[email-masked]>> 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?

  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 [email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sat, 17 Mar 2018 12:11:30 +0100

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 <[email-masked]> wrote:

>
>    - re privacy - the fact that someone with authority (over the domain)
> 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
>
> Staff Officer : Kate Atkins, [email-masked]
>
>
>
> *From:* dmarc <[email-masked]> *On Behalf Of *Kurt Andersen (b)
> *Sent:* 17 March 2018 09:41
> *To:* Steven M Jones <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dmarc-ietf] Agenda for IETF 101 DMARC session
>
>
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Mar 2018 11:01:38 -0700

>     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/