Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Jim Fenton]

On 6/13/20 8:17 PM, Dave Crocker wrote:
> On 6/13/2020 7:53 PM, Jim Fenton wrote:
>> Alas, others do,
>
> Other groups do all sorts of things.  They once mandated OSI, for
> example.
>
> Please explain how that is relevant, here and now.
The WG needs to consider the operational impact of DMARC deployment if
it is going to publish DMARC as a WG document.
>
> Are you perhaps suggesting that the technical work of the IETF should
> worry less about technical quality and more about possible use/abuse
> by other agencies?

That is a false dilemma. We can (and should) consider possible use/abuse
of specifications we publish, but that does not imply worrying less
about technical quality.

-Jim



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

Re: [dmarc-ietf] why ARC

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>> > ARC lets the recipient look back and retroactively do the filtering
>> > the list didn't.
>>
>> The concern about the creator of an ARC chain spoofing the purported
>> origin of a message is valid.
>
>By "creator" do you mean "initiator" (aka, the source of the first ARC set,
>i=1)?

I think it't the other way around. Let's say you get a message with
three ARC seals. For i=3 both the AMS and AS headers should validate,
since the message came directly from the entity that put on that seal.
For i=1 and i=2 the AS should validate but the AMS probably won't. The
cv= tag in each AS header tells us whether the AMS was good when it
arrived at that intermediary, so the i=1 and i=2 seals are only as
good as the i=3 signer's reputation.

I were a certain kind of bad guy, I would take the two seal ARC chain
from a message from a virtuous sender, replace the message body and
>From and Subject line with my spam, add a fresh new i=3 seal and blast
it out. That ARC chain is 100% valid, even though the messsage is
spam.

That's why (as Kurt knows) you only pay attention to ARC seals from
senders that are otherwise credible.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] why ARC

[Dave Crocker]

On 6/14/2020 10:25 AM, Kurt Andersen (b) wrote:
On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker > wrote:



> ARC lets the recipient look back and retroactively do the filtering
> the list didn't.

The concern about the creator of an ARC chain spoofing the purported
origin of a message is valid.


By "creator" do you mean "initiator" (aka, the source of the first ARC 
set, i=1)?


yes.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] why ARC

[Kurt Andersen (b)]

On Fri, Jun 12, 2020 at 5:52 PM Dave Crocker  wrote:

>
> > ARC lets the recipient look back and retroactively do the filtering
> > the list didn't.
>
> The concern about the creator of an ARC chain spoofing the purported
> origin of a message is valid.
>

By "creator" do you mean "initiator" (aka, the source of the first ARC set,
i=1)?

In general ARC chains are the product of a series of co-creators through
the handling sequence for the message, so I think that "creator" in a
singular sense is a little misleading.

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

[dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

[Hector Santos]

When we look at DKIM and the DMARC protocol by exposing the boundary 
conditions of the protocol, it helps with laying the groundwork for a 
protocol-complete model.


DKIM has three possible signature states:

- NONE (no valid signature)
- 1PS (1st party valid signature, Author.domain == Signer.domain)
- 3PS (3rd party valid signature, Author.domain != Signer.domain)

DMARC has three polices:

- none
- quarantine
- reject

With these 3x3=9 states, the following table with the boundary 
conditions of the protocol is established with the expected and 
potential actionable result:


DMARC POLICY
 +===+
 |// | p=NONE | p=QUARANTINE  | p=REJECT |
 |===|
  D  | NONE  | fail-pass  | fail-filter   | fail-reject  |
  K  |---++--|
  I  | 1PS   | pass   | pass  | pass |
  M  |---++--|
 | 3PS   | fail-pass  | fail-filter   | fail-reject  |
 +===+

Note: I intentionally left out SPF conditions for NONE, NEUTRAL, 
SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states. 
 For this exercise, we are assuming DMARC/SPF alignment is in play 
and failure can be for any DMARC known reason including the 3PS failed 
states.


The states for DKIM none and 1PS are expected protocol conditions. 
DMARC describes these conditions. But the DKIM 3PS conditions are not 
described and are subject to questionable actions because of the 
possible false positives results.


The 3PS failures occur because of the dearth for an Authorized Third 
party Signature protocol.  DMARC does not offer 3rd party signature 
solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But 
they did not restrict an ADD-ON extension to the protocol.


ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and 
when DMARC replaced ADSP, it equally applies to DMARC as well as an 
extension.  We do not need to get into the specific ATPS protocol 
details on how to authorize a 3rd party signer. Any "ATPS-like" 
protocol will only need to answer one question:


  Is the 3rd party (re)signer authorized?   Yes or NO

With this consideration, the table has one additional 3PS-AUTH row 
meaning Yes, the 3rd party (re)signer domain was authorized by the 
author domain.



   DMARC POLICY W/ ATPS
 +==+
 |//| p=NONE | p=QUARANTINE  | p=REJECT |
 |==|
  D  | NONE | fail-pass  | fail-filter   | fail-reject  |
  K  |--++--|
  I  | 1PS  | pass   | pass  | pass |
  M  |--++--|
 | 3PS  | fail-pass  | fail-filter   | fail-reject  |
 |--++--|
 | 3PS-AUTH | pass   | pass  | pass |
 +==+

Overall, as it was originally conceived, the DKIM Policy model can not 
ignore ATPS conditions because as you can see above, it would not be 
protocol-complete -- it is missing the 3PS-AUTH conditions.


While ADSP is a specific RFC proposed protocol, I am using it as an 
acronym for any authorizing third party signature concept:


   Result = DKIM_ATPS(author.domain, signer.domain)

Lets finish that part of the DKIM model.

Thanks

[1] https://tools.ietf.orgy/html/rfc5617
[2] https://tools.ietf.org/html/rfc6541

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos




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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Scott Kitterman]

On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote:
> Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
> > About this comment
> > 
> > If you teach users that "Joe User by Random Intermediary" is the same
> > as "Joe User", this expectation is doomed.> 
> > Based on the response to my previous post, "Trained User" is not a
> > meaningful concept, for purposes of this discussion [...]
> 
> That's not my point. My point is: this working group needs to make a
> determination whether From addresses being displayed to the users
> matters to DMARC or not, and then follow up consistently.
> 
> If it is, then don't break From addresses with munging.
> 
> If it is not, then use Sender field as a fallback for alignment, and
> don't break From either.

I don't think that's the question at all.

Whether user's knowledge of the from address has any bearing on anti-abuse 
methods or not, it has plenty of value for other purposes.  DMARC is not all 
of email.

>From rewriting is a gross hack that exists only due to dire necessity.  If 
this working group can't move the space towards a more usable solution, I'm 
not at all sure DMARCbis is worth the trouble.

Scott K



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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Kurt Andersen (b)]

On Fri, Jun 12, 2020 at 5:06 PM Scott Kitterman 
wrote:

>
> On June 12, 2020 11:33:13 PM UTC, "Kurt Andersen (b)" 
> wrote:
> >I would like to understand what you mean by:
> >
> >On Fri, Jun 12, 2020 at 1:02 AM Alessandro Vesely 
> >wrote:
> >
> >> . . . ARC chains can be forged.
>
> Not sure what is confusing about that.  There's no requirement that
> signatures from previous hops still verify, so anyone can build an ARC
> chain that claims they got something from an arbitrary source.  ARC is only
> usable if you know you trust the source.
>

Perhaps we are debating semantics here, but a wholesale replacement of the
message content within the bounds of an ARC-chain-span is not what I would
call "forgery". One can not simply "build an ARC chain" because each
ARC-Seal header is cryptographically created by the entities which control
the respective private keys.

Trust matters, but really has nothing to do with the interoperability or
validity of the chain itself.

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

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[devel2020]

Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :

About this comment
 
If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed.


Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this 
discussion [...]


That's not my point. My point is: this working group needs to make a 
determination whether From addresses being displayed to the users 
matters to DMARC or not, and then follow up consistently.


If it is, then don't break From addresses with munging.

If it is not, then use Sender field as a fallback for alignment, and 
don't break From either.


[...] > I suggest that the "Mailing List Problem" is a problem that does not 
need to be solved (and evidence suggests that it> cannot be solved.)   I 
can think of no purpose served by a public mailing list, like this one, 
which is not be better > solved by a community forum website with user 
login.


Thanks for you honesty. Then the relevant question is whether open and 
interoperable standards still matter, or if they should be replaced by 
proprietary web apps one feature at a time.


Cheers,
Baptiste

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