Subject: [dmarc-ietf] Working group next steps

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Mar 2019 17:57:33 +0100

DMARC colleagues,

Tim and I met in Prague to get things rolling in terms of getting us
progressing again toward our remaining deliverables.

Producing a DMARC on the standards track is the endgame for us.  We're keen
to identify and focus on work that is in direct service of that goal;
anything else can be parked for now and we can return to it once the main
work is done, assuming we still have the energy to do it.  Accordingly, we
propose to formally park draft-ietf-dmarc-arc-multi and
draft-ietf-dmarc-arc-usage.

The working group should, in the short term, focus on development and
completion of draft-ietf-dmarc-psd.  Among the questions to be answered is
its urgency: If there is pressure to get this finished and published in
some form, we suggest the WG consider moving this to Experimental status,
aligning it with the ARC base work, and come back around to merge it into
DMARC when it goes to the Standards Track.

Toward the goal of getting to the work on the standards track base
specification, we should start collecting issues, from nits on up to things
that need overhaul, in the WG's tracker.  We would like this list to be as
exhaustive as possible.  When we do finally get to the work of standards
track DMARC, we can run it like a checklist.  Please take some time to go
over the list that's already in the tracker, and add anything you think is
missing:

https://trac.ietf.org/trac/dmarc/report

You may need a login credential if you haven't already established one.
This can be done via the IETF datatracker: https://datatracker.ietf.org/

Previously (at IETF 99), the WG has discussed an augmentation of DMARC's
reporting capabilities to include attributes of ARC evaluation of a
message.  It's been suggested that this is a critical thing to include in
the ARC experiment and thus input to standards track DMARC work; it was
left out of ARC's base document to keep ARC decoupled from DMARC for now.
If consensus concurs with this position, we're looking for document
editor(s) to spin up that effort.  The chairs are, however, cognizant that
each new work item we take up has the effect of pushing standards track
DMARC further down the road, so we would like to keep this sort of thing to
a minimum.

Finally, there have been some hallway inquiries here at IETF 104 about
canonicalizations that can survive mailing list transit.  I thought it
worth checking with the WG to see if there's any energy or interest in
revisiting this kind of work; it does fit within our charter, but
previously attempts at this kind of work have waned.

We look forward to hearing your views on any or all of the above.  We can
start by having everyone begin logging their open DMARC specification
issues into the tracker, and ask that everyone please review and comment on
the PSD draft and provide comments.  In particular, anyone that has
implemented it is particularly requested to comment (including Scott, since
we imagine he's tried this by now).

-MSK

---

From: Seth Blank <[email-masked]>
Date: Tue, 26 Mar 2019 18:05:36 +0100

> DMARC when it goes to the Standards Track.

+1. This draft addresses several clear use cases and is critical to
standards track DMARC.

> DMARC further down the road, so we would like to keep this sort of thing to

+1. At IETF99 I signed up to be the author of this. I'm still happy to do
this work, and believe it's critical a) for the success of ARC, and b) for
standards track DMARC.

Seth

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Mar 2019 21:34:06 +0000

>+1. This draft addresses several clear use cases and is critical to

+1 here too.
As I understand it, getting this done sooner rather than later is important as supporting this operationally for non-CC TLDs requires ICANN changes that having it as an RFC would help.  These will probably take awhile, so it's important to started.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Mar 2019 23:45:17 -0400

Big time +1.  Focus on DMARC PSD! I agree with everything mentioned 
and hope to allocate time very soon to assist.

Thanks Murray, Great news!!

On 3/26/2019 12:57 PM, Murray S. Kucherawy wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 
HLS

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 27 Mar 2019 08:05:43 -0400

> > some form, we suggest the WG consider moving this to Experimental status
>

Yes, also +1 on moving PSD to experimental and advancing it through the
editorial process without further delay.

--Kurt

---

From: Ian Levy <[email-masked]>
Date: Fri, 29 Mar 2019 17:14:31 +0000

*   The working group should, in the short term, focus on development and completion of draft-ietf-dmarc-psd.  Among the questions to be answered is its urgency

I’m certainly keen to see that progressed. As we’ve rolled out DMARC across gov.uk subdomains, we’ve seen criminal behaviours change in response. Some of you may recall we asked for help a while ago for ideas in generating SPF/DMARC records for non-existent subdomains. Well, that’s running and we answered 430,000 queries for them between August and November last year (more current data coming). We do know that the effect of synthesising these records means that some receivers don’t honour them, so getting a more acceptable way of controlling subdomains of a PSD would be good. As we push for wider DMARC adoption and other authentication measures, we’ll need to do this much more widely so it needs to be easy.

I’ll also offer gov.uk as an experimental ground (within reason!).

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]<mailto:[email-masked]>

Staff Officer : Kate Atkins, [email-masked]<mailto:[email-masked]>

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)

From: dmarc <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: 26 March 2019 16:58
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] Working group next steps

DMARC colleagues,

Tim and I met in Prague to get things rolling in terms of getting us progressing again toward our remaining deliverables.

Producing a DMARC on the standards track is the endgame for us.  We're keen to identify and focus on work that is in direct service of that goal; anything else can be parked for now and we can return to it once the main work is done, assuming we still have the energy to do it.  Accordingly, we propose to formally park draft-ietf-dmarc-arc-multi and draft-ietf-dmarc-arc-usage.
Augu
The working group should, in the short term, focus on development and completion of draft-ietf-dmarc-psd.  Among the questions to be answered is its urgency: If there is pressure to get this finished and published in some form, we suggest the WG consider moving this to Experimental status, aligning it with the ARC base work, and come back around to merge it into DMARC when it goes to the Standards Track.

Toward the goal of getting to the work on the standards track base specification, we should start collecting issues, from nits on up to things that need overhaul, in the WG's tracker.  We would like this list to be as exhaustive as possible.  When we do finally get to the work of standards track DMARC, we can run it like a checklist.  Please take some time to go over the list that's already in the tracker, and add anything you think is missing:

https://trac.ietf..org/trac/dmarc/report<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fdmarc%2Freport&data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C062a4b0ea11b44be6b4f08d6b20c5478%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636892163368482447&sdata=5s9qVmp3DTBTZnZaKftSGOd6En%2FSTPnp9Rjeo58fHPo%3D&reserved=0>
You may need a login credential if you haven't already established one.  This can be done via the IETF datatracker: https://datatracker.ietf.org/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2F&data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C062a4b0ea11b44be6b4f08d6b20c5478%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636892163368482447&sdata=JAscZ7qbZcoTHqq2rlKy8k0AQ7RkGNNdbUcdkcn4xTk%3D&reserved=0>

Previously (at IETF 99), the WG has discussed an augmentation of DMARC's reporting capabilities to include attributes of ARC evaluation of a message.  It's been suggested that this is a critical thing to include in the ARC experiment and thus input to standards track DMARC work; it was left out of ARC's base document to keep ARC decoupled from DMARC for now.  If consensus concurs with this position, we're looking for document editor(s) to spin up that effort.  The chairs are, however, cognizant that each new work item we take up has the effect of pushing standards track DMARC further down the road, so we would like to keep this sort of thing to a minimum.
Finally, there have been some hallway inquiries here at IETF 104 about canonicalizations that can survive mailing list transit.  I thought it worth checking with the WG to see if there's any energy or interest in revisiting this kind of work; it does fit within our charter, but previously attempts at this kind of work have waned.

We look forward to hearing your views on any or all of the above.  We can start by having everyone begin logging their open DMARC specification issues into the tracker, and ask that everyone please review and comment on the PSD draft and provide comments.  In particular, anyone that has implemented it is particularly requested to comment (including Scott, since we imagine he's tried this by now).

-MSK

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: Scott Kitterman <[email-masked]>
Date: Fri, 29 Mar 2019 13:18:47 -0400

On Friday, March 29, 2019 05:14:31 PM Ian Levy wrote:
>   *   The working group should, in the short term, focus on development and
> its urgency
 
> I’m certainly keen to see that progressed. As we’ve rolled out DMARC across
> gov.uk subdomains, we’ve seen criminal behaviours change in response. Some
> of you may recall we asked for help a while ago for ideas in generating
> SPF/DMARC records for non-existent subdomains. Well, that’s running and we
> answered 430,000 queries for them between August and November last year
> (more current data coming). We do know that the effect of synthesising
> these records means that some receivers don’t honour them, so getting a
> more acceptable way of controlling subdomains of a PSD would be good. As we
> push for wider DMARC adoption and other authentication measures, we’ll need
> to do this much more widely so it needs to be easy.
 
> I’ll also offer gov.uk as an experimental ground (within reason!).

Excellent.  I've listed it in the experimental registry at psddmarc.org.  
Since you already had a live DMARC record for that domain, people can 
experiment with this now.

Scott K

---

From: Ian Levy <[email-masked]>
Date: Sun, 31 Mar 2019 10:18:16 +0000

> Since you already had a live DMARC record for that domain, people can experiment with this now.

I guess at some point we'll have to stop generating SPF and DMARC records for the non-existent subdomains of gov.uk so we can test the new stuff properly. When we're at that point, let me know.

Ta.

I.

[email-masked]

Staff Officer : Kate Atkins, [email-masked]

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sun, 31 Mar 2019 08:38:44 -0400

Certainly not.   
  
 You cannot drop existing defenses until the new standard is 100% deployed on the Internet, which means probably never.    Your experimental implementation will need to prioritize the new test over the SPF test, to prove that it is working and to show that it is good at intercepting any subdomains that have been newly imagined by the attackers
  
 To speed up the deployment process for existing or new standards, IETF would meed to embrace the idea of defining required features of a spam filter.
  
 Doug Fosterd

----------------------------------------
 From: "Ian Levy" <ian.levy=[email-masked]>
Sent: Sunday, March 31, 2019 6:18 AM
To: "Scott Kitterman" <[email-masked]>, "IETF DMARC WG" <[email-masked]>
Subject: Re: [dmarc-ietf] Working group next steps   
>> I'll also offer gov.uk as an experimental ground (within reason!).

Ta.

I.

(I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!)

---

From: Dotzero <[email-masked]>
Date: Sun, 31 Mar 2019 14:39:24 -0400

Douglas,

Can you show us a single email authentication standard that is 100%
deployed on the Internet? There isn't anything that comes close to that
achievement. Even things like DNS are not 100%. I know hosts that are only
reachable by IP address.

Michael Hammer

On Sun, Mar 31, 2019 at 2:31 PM Douglas E. Foster <
[email-masked]> wrote:

> Certainly not.
>
> You cannot drop existing defenses until the new standard is 100% deployed
> on the Internet, which means probably never.    Your experimental
> implementation will need to prioritize the new test over the SPF test, to
> prove that it is working and to show that it is good at intercepting
> any subdomains that have been newly imagined by the attackers
>
> To speed up the deployment process for existing or new standards, IETF
> would meed to embrace the idea of defining required features of a spam
> filter.
>
> Doug Fosterd
>
> ------------------------------
> *From*: "Ian Levy" <ian.levy=[email-masked]>
> *Sent*: Sunday, March 31, 2019 6:18 AM
> *To*: "Scott Kitterman" <[email-masked]>, "IETF DMARC WG" <
> [email-masked]>
> *Subject*: Re: [dmarc-ietf] Working group next steps
>
> > Excellent. I've listed it in the experimental registry at psddmarc.org..
> I guess at some point we'll have to stop generating SPF and DMARC records
> for the non-existent subdomains of gov.uk so we can test the new stuff
> properly. When we're at that point, let me know.
>
> Ta.
>
> I.
>
> --
> Dr Ian Levy
> Technical Director
> (I work stupid hours and weird times – that doesn’t mean you have to. If
> this arrives outside your normal working hours, don’t feel compelled to
> respond immediately!)
>
>
> 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: Ian Levy <[email-masked]>
Date: Sun, 31 Mar 2019 19:07:16 +0000

The existing defences aren’t 100% even before the evil kludge we’ve put up for non existent subdomains, which certainly is not working everywhere. The PSD draft, when implemented, will help scale existing defences to make evolution of criminal behaviour harder and do it in a standardised way so that it’s more likely to be consistently implemented.  That’s worth us collectively doing some work and me taking some risk to help early testing.

Nothing is 100% in security. Except possibly the existence of a preponderance of marketing hype :-).

Ta.

I.

—
Dr Ian Levy
Technical Director

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)
________________________________
From: dmarc <[email-masked]> on behalf of Douglas E. Foster <[email-masked]>
Sent: Sunday, March 31, 2019 7:31 pm
To: Scott Kitterman; IETF DMARC WG; Ian Levy
Subject: Re: [dmarc-ietf] Working group next steps

Certainly not.

Doug Fosterd

________________________________

Ta.

I.