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

[John Levine]

In article  you write:
>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.

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 7/18/2017 7:20 AM, Murray S. Kucherawy wrote:
On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen > 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 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?



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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Tue, Jul 18, 2017 at 1:34 PM, Kurt Andersen  wrote:

>
> I don't understand. Mediators ARC sign, the header is everything you need
>> 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?
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

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.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

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.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Seth Blank]

On Tue, Jul 18, 2017 at 4:34 AM, Kurt Andersen  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
> servers, how would they do that?
>

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.)


> 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 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 ;-)
>>
>
> I realize that you can not vouch for yourself, but you can say that you
> 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.


> --Kurt
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Kurt Andersen]

On Tue, Jul 18, 2017 at 1:30 PM, Seth Blank  wrote:

> On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen  wrote:
>
>> During today's lunch conversation, the question of how we can reasonably
>> 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?
>

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?


> 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 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 ;-)
>

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

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Seth Blank]

On Tue, Jul 18, 2017 at 4:00 AM, Kurt Andersen  wrote:

> During today's lunch conversation, the question of how we can reasonably
> 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?


> 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 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 ;-)


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