Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Dec 2019 12:40:41 -0800

On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker <[email-masked]> wrote:

> On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
>
> * add text to the PSD draft making it clear that what it's describing is
> an experiment whose outcome will be taken only as feedback to the revision
> of the standard (i.e., this is not intended to be the final form of
> anything), and it is not intended to be deployed outside of the
> experiment's participants;
>
> Forgive me, but while everyone involved in this has extensive experience
> and is trying to solve a real and serious issue, this is an astonishingly
> naive view.
>
> The IETF does standards, not experiments.  Not /real/ experiments.  What
> it calls an experiment mostly serves as market testing, with a smidgen of
> engineering tuning later.  For the most part, IETF experiments produce an
> accepted/failed/needs-small-revisions range of results.  What it does /not/
> produce is results along the lines of "that was interesting, now let's
> start fresh and do the real standard."
>
> Perhaps there are exampls of IETF experiments that have permitted entirely
> starting over, but mostly those only happen when there is a complete
> failure, and those typically are called experiments.
>
Should I take this as advocating for running the experiment without
publishing an RFC about it?  Or do you have another suggestion?

I don't think the idea of going back and fixing the DMARC-PSL separation
issue first is tenable given how long it will take, compared to the urgent
need to get some data here.

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 3 Dec 2019 12:46:29 -0800

I think that if we could get a core set of receivers who would be willing
to test this and report on their findings in 3-6 months, that would be
great.

--Kurt

On Tue, Dec 3, 2019 at 12:40 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> Perhaps there are exampls of IETF experiments that have permitted
>> entirely starting over, but mostly those only happen when there is a
>> complete failure, and those typically are called experiments.
>>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Dec 2019 23:42:09 -0800

> and is trying to solve a real and serious issue, this is an astonishingly
I don't think it's based entirely on naivety.  I think there's a healthy
dose of feeling that the experiment as it's currently designed couldn't
possibly scale to "the entire domain namespace" and/or "all servers on the
Internet", so in that sense from where I sit there's a built in safeguard
against this becoming a permanent wart.  Rather, it's primed as a possibly
useful data collection exercise.

Comparing it to the "obs" grammars of days of yore, the PSD proposal is
much too expensive to become engrained as-is, whereas the old grammars were
relatively easy to carry forward.

> failure, and those typically are called experiments.
ATPS (RFC 6541) was Experimental, and it flatly failed.  For a more visible
example, Sender ID was Experimental, and I would argue it did too.  Should
they not have been?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Dec 2019 11:39:43 +0100

On Wed 04/Dec/2019 08:42:09 +0100 Murray S. Kucherawy wrote:
> On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>>>   an experiment whose outcome will be taken only as feedback to the
>>>   revision of the standard (i.e., this is not intended to be the final form
>>>   of anything), and it is not intended to be deployed outside of the
> I don't think it's based entirely on naivety.  I think there's a healthy dose
> of feeling that the experiment as it's currently designed couldn't possibly
> scale to "the entire domain namespace" and/or "all servers on the Internet", so
> in that sense from where I sit there's a built in safeguard against this
> becoming a permanent wart.

After installing the DKIM/DMARC filter that implements PSD, I can say that the
impact is unnoticeable.  I didn't carry out precise measurements, I just didn't
notice any delay.  Perhaps because I don't get so much mail from gov.uk, but I
don't think I could reliably measure a positive delay even if I were a strict
correspondent of Boris.

> Rather, it's primed as a possibly useful data collection exercise.

Kurt also talked about reporting some findings.  I'm embarrassed, I have no
idea what I, as a receiver, should report.  What data should I, and other
receivers collect?

IMHO, the experiment should be conceived as having it run by as many receivers
as possible, so as to have a noticeable effect on senders.  They can collect
aggregate reports and make a comparison.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 4 Dec 2019 10:01:28 -0800

> idea what I, as a receiver, should report.  What data should I, and other

I was thinking of something along the line of what was assembled for RFC
6686. In this case it would be something like the quantity of messages
which were assessed against the LPSD record and their disposition compared
to the number of messages dispositioned at the org level. Something to
answer Dave's concern about "too much additional work" for not enough
benefit.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Wed, 4 Dec 2019 17:04:00 -0800

> answer Dave's concern about "too much additional work" for not enough

Remind me again the the additional work is that might be too much?  Isn't
it just another DNS lookup for the org domain -1... of which there are
maybe a couple thousand and easily cacheable?

This seems way less than say the additional work for ARC.

Brandon

---

From: Ian Levy <[email-masked]>
Date: Fri, 6 Dec 2019 08:00:48 +0000

> Perhaps because I don't get so much mail from gov.uk

Ale,
We can fix that for you if you want :-). 

Seriously, if you want to try some volume testing, let me know off-list and we'll try to sort something out. 

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email-masked]

Staff Officer : Kate Atkins, [email-masked]
Pronouns : he/him

(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!)

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
Sent: 04 December 2019 10:40
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Wed 04/Dec/2019 08:42:09 +0100 Murray S. Kucherawy wrote:
>>  Forgive me, but while everyone involved in this has extensive 
>> experience  and is trying to solve a real and serious issue, this is 
>> an astonishingly  naive view.
>
> I don't think it's based entirely on naivety.  I think there's a 
> healthy dose of feeling that the experiment as it's currently designed 
> couldn't possibly scale to "the entire domain namespace" and/or "all 
> servers on the Internet", so in that sense from where I sit there's a 
> built in safeguard against this becoming a permanent wart.

After installing the DKIM/DMARC filter that implements PSD, I can say that the impact is unnoticeable.  I didn't carry out precise measurements, I just didn't notice any delay.  Perhaps because I don't get so much mail from gov.uk, but I don't think I could reliably measure a positive delay even if I were a strict correspondent of Boris.

> Rather, it's primed as a possibly useful data collection exercise.

Kurt also talked about reporting some findings.  I'm embarrassed, I have no idea what I, as a receiver, should report.  What data should I, and other receivers collect?

IMHO, the experiment should be conceived as having it run by as many receivers as possible, so as to have a noticeable effect on senders.  They can collect aggregate reports and make a comparison.

Best
Ale
--

_______________________________________________
dmarc mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C969a778d73d4449d0d5708d778a64df4%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637110527988698509&amp;sdata=IUFTCWhr1rc6I7vWMTk26NpayRjxXsnV4qqAU%2BmoOPg%3D&amp;reserved=0
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]. All material is UK Crown Copyright ©

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 07 Dec 2019 15:11:13 -0500

> This seems way less than say the additional work for ARC.

It's slightly more.  There's also a check to see if a LPSD (org -1) is a PSD 
DMARC participant.  Exactly how to document that is the major unresolved 
question that we should evaluate experimentally.  It might be one of three 
things:

1.  A registry that is occasionally updated and consumed locally.
2.  A DNS RBL type service lookup.
3.  An exended PSL.

Options 2 and 3 both have a second additional lookup.  Personally, I like 
option 1, but there's no consensus about this.  There are working versions of 
all three available from psddmarc.org for testing.

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 8 Dec 2019 14:49:43 -0500

Scott

Instead of thinking one must choose between a locally consumed registry and
a lookup service, why not both?
In the land of DNSOP we put out RFC7706 which talks about running a copy of
the root Nameservers locally to
speed lookups.  This seems to be so highly useful that we're just finished
WGLC on 7706-bis.

So we could decide on doing a combinatory of #3 and #1, with the right
mechanisms.

Just a thought.

Tim
(lacking any hats today)

On Sat, Dec 7, 2019 at 3:11 PM Scott Kitterman <[email-masked]> wrote:

> > >> Kurt also talked about reporting some findings.  I'm embarrassed, I
> have
> > >> no
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2019 16:58:20 -0500

>So we could decide on doing a combinatory of #3 and #1, with the right

Publishing a list of PSD superdomains in the DNS is pretty trivial
using my dbound scheme, and should typically find out whether any name
needs a PSD check with one DNS query.  The total zone for the PSL is
under 10K records, so doing a local mirror should be easy, too.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 8 Dec 2019 20:58:10 -0500

+1

Tim
(just a fan of
https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt)

---

From: "John R Levine" <[email-masked]>
Date: 8 Dec 2019 21:18:41 -0500

> https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt)

Don't miss https://github.com/jrlevine/bound

I found and fixed a bunch of bugs in the spec when I implemented it.  Who 
knew that could happen?

>> under 10K records, so doing a local mirror should be easy, too.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Dec 2019 08:44:22 -0800

On 12/3/2019 11:42 PM, Murray S. Kucherawy wrote:
...
 >        I think there's a healthy
> dose of feeling that the experiment as it's currently designed
> built in safeguard against this becoming a permanent wart.  Rather,
> it's primed as a possibly useful data collection exercise.
The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale.  (While I think of this concern as
foundational to the IETF, it's a bit odd that nothing like it is
included in the IETF's "Mission and principles" statement.[1])

Perhaps even more importantly, I don't recall the IETF ever promoting a
specification that was /expected/ to be thrown away, in favor of then
doing the 'real' specification.  I do believe such work is sometimes
done in the I/R/TF.  Note that, for example, this view of throwing a 
spec away and starting over is quite different from wanting to let the 
market choose between competing specs.

Also, viewing this scaling limitation as a safeguard has recently and
notably proved wrong.  cf, DMARC.  It was designed for a very limited
scenario. Then it got re-purposed in the field, by some operators having
significant leverage.

Worse, publishing a spec always carries the likelihood of operational
momentum. If the spec has real utility, it tends to get implemented and
used.  That creates pressure against replacing it, because that's
expensive and possibly disruptive.

> Comparing it to the "obs" grammars of days of yore, the PSD proposal
> is much too expensive to become engrained as-is, whereas the old
> grammars were relatively easy to carry forward.

I don't quite grok the reference to "obs", and mostly think of the
introduction of that construct in RFC 2822 as an interesting idea that,
itself, failed.  (I see it as being instructive on the challenges of
designing for transition from an installed base.)

> ATPS (RFC 6541) was Experimental, and it flatly failed.  For a more 
> visible example, Sender ID was Experimental, and I would argue it did
>  too.  Should they not have been?

All sorts of experimental specs fail.  But they aren't /expected/ to
fail.  And they aren't expected to be unable to scale.

Mostly, IETF/Experimental is used to check whether a spec is
operationally viable -- it's expected to be but the community isn't
quite sure -- or to check for community interest.  The latter
constitutes market research, not technical research.

A pointedly friendly reading of the relevant Guidelines might seem to
support the publication under IETF/Experimental being proposed here, but
a more critical one probably doesn't and I think that this use of the
label doesn't really match common practice.[2]

On 12/7/2019 12:11 PM, Scott Kitterman wrote:
>> Remind me again the the additional work is that might be too much?
>> Isn't it just another DNS lookup for the org domain -1... of which
>> there are maybe a couple thousand and easily cacheable?
>> 
> It's slightly more.  There's also a check to see if a LPSD (org -1)
> is a PSD > DMARC participant.  Exactly how to document that is the major
> unresolved question that we should evaluate experimentally.  It might
> be one of three
> things:

First, this sort of exchange highlights the need for considering basic 
operational issues carefully and before publication.

Second, it highlights the challenges of doing that in a way that isn't 
myopic.  What is easy/cheap for highly motivated, expert, well-resourced 
participants might not be all that easy or cheap for the larger Internet 
community.  (This is the operational side of scalability.)

The real challenge for most IETF specs is community engagement, not 
engineering adequacy.

Some additional thoughts:

The example that Tim added, of RFC 7706, is of an efficiency mechanism, 
not a basic and required addition to the architecture. The difference is 
important here.

Also, any suggestion to rely on a published list ignores the history of 
problems with such lists, as well as at least requiring a careful 
specification for the list and a basis for believing it will be 
maintained well.

d/

[1] Mission and principles

[2] https://ietf.org/standards/process/informational-vs-experimental/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brandon Long <[email-masked]>
Date: Mon, 9 Dec 2019 16:41:27 -0800

> community.  (This is the operational side of scalability.)

Ah, re-reading the spec, I'd guess we're talking about the scalability of
psddmarc.org.

[snip]

> specification for the list and a basis for believing it will be

I mean, the PSL is already a maintained object.  Is this new detail
something
that has different ownership/privacy/etc concerns than the existing details?

I'm sure I probably missed this, but couldn't we avoid this question by
just mandating
no reporting for non-existing organizational domains?  Is that a
non-starter?

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Dec 2019 19:54:10 -0500

> Ah, re-reading the spec, I'd guess we're talking about the scalability of

It's only relevant for the purposes of the experiment.  Part of coming to 
consensus on the longer term plan would be making sure we have a scalable 
approach for determining PSD DMARC participants.

> no reporting for non-existing organizational domains?  Is that a

It's one of the use cases we are trying to cover.  I don't know if that makes 
it a non-starter.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 9 Dec 2019 18:26:36 -0800

On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman <[email-masked]> wrote:

> just mandating no reporting for non-existing organizational domains?  Is
> that a non-starter?
>
> It's one of the use cases we are trying to cover.  I don't know if that
> makes it a non-starter.
>

Unless I'm misunderstanding Brandon's suggestion, it seems like you
(Brandon) are asking if doing no reporting on missing org domains solves
the scalability problem. *Getting* reports for missing org domains is the
main purpose of the PSD proposal so it would render the purpose moot.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Dec 2019 18:33:39 -0800

> that has different ownership/privacy/etc concerns than the existing 

So, ummm, you want to replace one problematic operation with another?

On the consumption side, I've only heard comments that the PSL has 
problems.  On the provision side, I've heard vigorous and repeated 
claims of overwork of the the volunteer force, sufficient that there is 
no bandwidth for dealing with revision/replacement efforts.

> I'm sure I probably missed this, but couldn't we avoid this question 
> by just mandating

Without commenting on the merits of that suggesting, I'll offer that it 
is an example of why this spec is -- at its very best -- still 
incomplete, or at least the thinking about how it will get used is 
incomplete. (if workable at scale.)

d/

---

From: Brandon Long <[email-masked]>
Date: Tue, 10 Dec 2019 14:13:21 -0800

> main purpose of the PSD proposal so it would render the purpose moot.

Hmm, I guess I don't see it that way.

Preventing phishing attacks from nonexistent.gov.uk, insomuch as DMARC can
be used for such, seems way more important than the reporting.  Obviously,
getting to p=reject without reporting is more challenging.  You can
certainly have policy without reporting.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 10 Dec 2019 14:15:21 -0800

> So, ummm, you want to replace one problematic operation with another?
DMARC already depends on the PSL, so an extension that also depends on it
doesn't seem out of place.

> problems.  On the provision side, I've heard vigorous and repeated claims
> of overwork of the the volunteer force, sufficient that there is no
> bandwidth for dealing with revision/replacement efforts.
>
Understandable.

Brandon

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 Dec 2019 07:45:32 -0800

On Tue, Dec 10, 2019 at 2:13 PM Brandon Long <[email-masked]> wrote:

>>> by just mandating no reporting for non-existing organizational domains?  Is
>>> that a non-starter?
>>>
> Preventing phishing attacks from nonexistent.gov.uk, insomuch as DMARC
> can be used for such, seems way more important than the reporting.
> Obviously, getting to p=reject without reporting is more challenging.  You
> can certainly have policy without reporting.
>

While it is very true that receivers may implement validation and possibly
enforcement without reporting, we could solve the use case of phishing from
missing org-level domains by the same approach that we can solve it from
any missing domain - just don't accept mail from such bogus sources. That
does not help the overseers of a domain realm (org-1, aka LPSD) to tackle
takedowns or public awareness campaigns against such abuse though.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Thu, 12 Dec 2019 15:37:52 -0800

> takedowns or public awareness campaigns against such abuse though.

I mean, that was also true for all DMARC, the point was the owner was
asking everyone to do that.  If you're saying we should have a different
system for trying to get everyone to not accept messages from non-existent
domains... ok, but I'm not sure where that would come from.

Maybe no one would be willing to go with np=reject without being able to
confirm there's no good mail doing that.  That seems more likely to be true
for existing large scale branded domains (which I guess gov.uk falls into),
whereas setting that policy for the newer branded domains (.google) and
multi-organizational (.bank) seems fine without reporting.

Brandon

---

From: Ian Levy <[email-masked]>
Date: Fri, 20 Dec 2019 13:32:24 +0000

*   Maybe no one would be willing to go with np=reject without being able to confirm there's no good mail doing that.

Exactly this. As we’ve pushed DMARC across gov.uk we’ve found all sorts of interesting things in the reporting we get.

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]>
Pronouns : he/him

From: dmarc <[email-masked]> On Behalf Of Brandon Long
Sent: 12 December 2019 23:38
To: Kurt Andersen (b) <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>; Scott Kitterman <[email-masked]>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Wed, Dec 11, 2019 at 7:45 AM Kurt Andersen (b) <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Dec 10, 2019 at 2:13 PM Brandon Long <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b) <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman <[email-masked]<mailto:[email-masked]>> wrote:
On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:

> I'm sure I probably missed this, but couldn't we avoid this question by just mandating no reporting for non-existing organizational domains?  Is that a non-starter?

It's one of the use cases we are trying to cover.  I don't know if that makes it a non-starter.

Unless I'm misunderstanding Brandon's suggestion, it seems like you (Brandon) are asking if doing no reporting on missing org domains solves the scalability problem. *Getting* reports for missing org domains is the main purpose of the PSD proposal so it would render the purpose moot.

Preventing phishing attacks from nonexistent.gov.uk<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnonexistent.gov.uk&data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C522306c0a8a84aca4a7308d77f5c5d4b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637117906987236215&sdata=Be5QRL1NweewdLl2E6UbuliKRWqAEZb0KPS7YW8nn5E%3D&reserved=0>, insomuch as DMARC can be used for such, seems way more important than the reporting.  Obviously, getting to p=reject without reporting is more challenging.  You can certainly have policy without reporting.

While it is very true that receivers may implement validation and possibly enforcement without reporting, we could solve the use case of phishing from missing org-level domains by the same approach that we can solve it from any missing domain - just don't accept mail from such bogus sources. That does not help the overseers of a domain realm (org-1, aka LPSD) to tackle takedowns or public awareness campaigns against such abuse though.

I mean, that was also true for all DMARC, the point was the owner was asking everyone to do that.  If you're saying we should have a different system for trying to get everyone to not accept messages from non-existent domains... ok, but I'm not sure where that would come from.

Maybe no one would be willing to go with np=reject without being able to confirm there's no good mail doing that.  That seems more likely to be true for existing large scale branded domains (which I guess gov.uk<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgov.uk&data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C522306c0a8a84aca4a7308d77f5c5d4b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637117906987246211&sdata=ADl8m4tEnSW2tzuk6dWIVU7sx8Y%2BRUQ%2FS1cffxjsuOU%3D&reserved=0> falls into), whereas setting that policy for the newer branded domains (.google) and multi-organizational (.bank) seems fine without reporting.

Brandon