Subject: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC

From: Kurt Andersen <[email-masked]>
Date: Tue, 18 Jul 2017 13:00:17 +0200

During today's lunch conversation, the question of how we can reasonably
scale recipients being able to identify mediators came up.

We've suggested (during M3AAWG sessions) that smaller recipients can build
out a whitelist of "commonly seen" mediators, but might there be value in
having a mediator publish some sort of DNS record that would indicate that
they ARC seal mediated traffic? (We're deeming this not to be a problem for
"big" receivers on the basis that they probably already know most of the
major mediators within their traffic streams.)

This might be an extension to the existing _dmarc record or perhaps a new
_arc record type.

How would recipients know to look for this record if the mediated traffic
doesn't have a "from" in the mediator's domain space? Should they look at
domain(s) information in the List- headers?

I wanted to get this out to the list for consideration before Thursday's
discussion so that we could possibly consider this during the AOB section
of the agenda.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Tue, 18 Jul 2017 04:30:06 -0700

> scale recipients being able to identify mediators came up.

I don't understand. Mediators ARC sign, the header is everything you need
for this identification, is it not?

> major mediators within their traffic streams.)

This is not why the white list exists. The white list exists as a
short-term hack for people without internal reputation systems to determine
trusted intermediaries (like the IETF, apache.org, etc.). Me publishing
that I'm trusted on my own DNS doesn't help ;-)

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

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 18 Jul 2017 13:34:42 +0200

> for this identification, is it not?

Let's take ietf.org as an example. There are @ietf.org individuals and then
there are all the mailing lists. If IETF wished to assert to receivers that
all their mail was either mediated or came from designated internal
servers, how would they do that?

> that I'm trusted on my own DNS doesn't help ;-)

I realize that you can not vouch for yourself, but you can say that you
participate in ARC for mediated mail.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Tue, 18 Jul 2017 05:37:22 -0700

On Tue, Jul 18, 2017 at 4:34 AM, Kurt Andersen <[email-masked]> wrote:
>
> Let's take ietf.org as an example. There are @ietf.org individuals and
> then there are all the mailing lists. If IETF wished to assert to receivers
> that all their mail was either mediated or came from designated internal

I don't understand why this distinction matters. Either you send email that
authenticates and gets delivered, or that fails authentication but is ARC
signed and gets delivered. Everything else gets rejected or heavily
scrutinized. Where would this distinction add clarity or prevent abuse?
(I'm not saying it doesn't, just that I don't see it.)

> participate in ARC for mediated mail.

But isn't saying I participate in ARC done by ARC sealing a message?

And conversely, what if I'm ARC signing but either a) don't properly update
my DNS, or b) have a malformed DNS entry? Does this mean my good ARC
signature is thrown away? This feels like an avenue for operational
complexity that could slow ARC adoption. Upgrading your software to
properly seal messages is a low bar and we shouldn't increase the
complexity unless there's exceptional value to be gained.

---

From: Steven M Jones <[email-masked]>
Date: Tue, 18 Jul 2017 15:42:15 +0200

On 07/18/2017 01:00 PM, Kurt Andersen wrote:
>
> We've suggested (during M3AAWG sessions) that smaller recipients can
> build out a whitelist of "commonly seen" mediators, but might there be
> value in having a mediator publish some sort of DNS record that would
> indicate that they ARC seal mediated traffic?

That whitelist - if I'm not confused - is used by the small/medium
receiver to identify ARC intermediaries whose ARC-sealed authentication
information they can take as accurate. In other words, that they can
_trust_ ARC information from those intermediaries... It's the stand-in
for the sophisticated reputation systems that the large receivers
already have.

The problems with self-identifying oneself as trustworthy are pretty
clear...

I'm missing what the other use for this information would be. What's the
result of plugging this information into the small/medium receiver's
filters?

--S.

---

From: Steven M Jones <[email-masked]>
Date: Tue, 18 Jul 2017 16:08:07 +0200

--S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Jul 2017 16:20:33 +0200

> servers, how would they do that?

Why should receivers trust such an assertion by a domain they have not
already decided to trust?  Couldn't a bad actor make such a claim in an
attempt to get preferential treatment?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jul 2017 07:57:00 -0700

On 7/18/2017 7:20 AM, Murray S. Kucherawy wrote:
> On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>     Let's take ietf.org <http://ietf.org> as an example. There are
>     @ietf.org <http://ietf.org> individuals and then there are all the
>     mailing lists. If IETF wished to assert to receivers that all their
>     mail was either mediated or came from designated internal servers,
>     how would they do that?
> 

Exactly.

The concept of whitelisting seems to parallel use of that construct 15 
or so years ago.  It has some utility in simple cases, but does not 
scale well and does not deal well with the dynamics of today's world of 
email system compromise...

ARC is an underlying authentication mechanism that calls for a new 
assessment mechanism, since the role of the authenticated entity is 
different than the entities currently being assessed by filtering 
engines -- intermediary rather than originator.

It is possible that simply re-using current assessment mechanisms will 
suffice -- I can easily imagine that working well -- but it seems 
equally possible that different mechanisms will be needed.  This open 
question about how ARC authentication will get used is one of the 
reasons I think the industry needs to deploy ARC experimentally for 
awhile, to develop some real-world operational experience with the 
dynamics of using it, beyond the early experience already being gained.

That's why I've suggested that being able to write a stable "Using ARC" 
BCP would be a pragmatic milestone for deciding that ARC is appropriate 
for formal standardization.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2017 15:52:02 -0000

>engines -- intermediary rather than originator.

Well, yes, but for ARC you need a bottom turtle that tells you whether
to mix the advice from the ARC chain into your message assessment.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jul 2017 09:04:21 -0700

> to mix the advice from the ARC chain into your message assessment.

Not sure what the 'but' is meant to contrast with.

In claiming that figuring out how to add the assessment component, I'd 
expect the figuring to include such consiuderations and 'whether ]and 
how] to mix the advice' in...

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Jul 2017 15:57:48 -0700

> participate in ARC for mediated mail.

My concern is similar to what others already are expressing:  I'm not 
clear what the security-related benefit would be.

Publishing an 'I participate in ARC' record seems naturally reasonable, 
but I can't figure out how it would get used meaningfully.

d/