Subject: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 10 May 2016 10:23:16 -0700

Updated the subject line to start a new thread. . .sorry for the confusion.

On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) <[email-masked]>
wrote:

> On Thu, May 5, 2016 at 6:54 AM, Tim Draegen <[email-masked]> wrote:
>
>> The WG will now move ahead to phase 2:
>>
>>   https://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki
>>
>> When discussing methods and techniques that address an interoperability
>> issue, please explicitly reference the issue from the
>> draft-ietf-dmarc-interoperability draft.  This will allow for easier
>> tracking of issues & proposed fixes by volunteers a lot easier.
>>
>
> I would like to officially propose, and ask for the WG's support of
> adopting https://datatracker.ietf.org/doc/draft-andersen-arc/ and the
> corresponding, but separate usage recommendations
> https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as
> standards-track documents within the WG to help mitigate the
> interoperability problems that were cataloged.
>
> Specifically, in draft -09 of the interop document, I had cited ARC in
> section 4.2 as an instance of a "[m]echanism[s] to extend
> Authentication-Results [RFC7601] to multiple hops. . ." (
> https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2)
> but subsequently abstracted that "work in progress" out of the document to
> honor our milestone framework.
>
> --Kurt Andersen
>

---

From: Steven M Jones <[email-masked]>
Date: Tue, 10 May 2016 11:08:48 -0700

On 05/10/2016 10:23, Kurt Andersen (b) wrote:
> On Tue, May 10, 2016 at 10:21 AM, Kurt Andersen (b) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Thu, May 5, 2016 at 6:54 AM, Tim Draegen <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         When discussing methods and techniques that address an
>         interoperability issue, please explicitly reference the issue
>         from the draft-ietf-dmarc-interoperability draft.  This will
>         allow for easier tracking of issues & proposed fixes by
>         volunteers a lot easier.
>
>
>     I would like to officially propose, and ask for the WG's support
>     of adopting https://datatracker.ietf.org/doc/draft-andersen-arc/
>     and the corresponding, but separate usage recommendations
>     Specifically, in draft -09 of the interop document, I had cited
>     ARC in section 4.2 as an instance of a "[m]echanism[s] to extend
>     Authentication-Results [RFC7601] to multiple hops. . ."
>     (https://trac.tools.ietf.org/html/draft-ietf-dmarc-interoperability-09#section-4.2)
>     but subsequently abstracted that "work in progress" out of the
>     document to honor our milestone framework.
>

+1

I'd like to reinforce this call. ARC has great promise, but we're just
completing and testing initial implementations. There are frequent
discussions of specification changes (on arc-discuss and elsewhere),
which shows that there's substantive work to be done - and that work can
only benefit from the broader community that an IETF WG represents.

--Steve.

Steven M Jones
DMARC.org
e: [email-masked], [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 May 2016 11:48:31 -0700

> only benefit from the broader community that an IETF WG represents.

Perhaps it will aid consideration if a candidate list of such work is 
offered?  A summary of issues raised in those discussions, so far.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brandon Long <[email-masked]>
Date: Tue, 10 May 2016 14:03:34 -0700

> offered?  A summary of issues raised in those discussions, so far.

One thing we still need to determine is how to make arc forward compatible
with changes, the most obvious of which is that it currently relies on
rsa-sha256 for its signatures, we need to determine how to make it possible
to transition to a new signature algorithm.

I also brought up to a smaller group as we were discussing what is the
payload for arc, whether we are content with the payload being just the
ARC-Authentication-Results header.  ARC provides a mechanism for passing
forward verifiable information, and the content is the AAR.  I worry that
folks may try to extend the AAR to other things in order to take advantage
of that.  I'm not sure if that means we should consider changes to that or
not.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 10 May 2016 16:13:56 -0700

Another question to consider that relates to DMARC directly (and I admit to
being rather off the cuff at this point):

Some folks say that DMARC works well for transactional domains, and not so
well when applied to end user / general purpose domains.

Should DMARC add a policy setting for whether the domain owner feels that
ARC should be used to bypass regular DMARC evaluation?

Almost like a "strict" vs "not strict".  High enough value targets may not
want to allow any message modification.

Of course, most high value targets still use their domains for multiple
purposes (ie, corporate mail on transactional domains), so maybe this is a
bad idea.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 11 May 2016 00:23:03 -0000

>ARC should be used to bypass regular DMARC evaluation?

Please, no.  One approach to what we can oversimplify as the mailing
list problem is to do it from the sending end, with the sender using
something like conditional double signatures to say mutated messages
are OK.  The other is to provide data that the recipient can use
to decide these mutations are OK.

ARC is definitely in the latter camp, and it would be painful to
have both ends arguing about how OK stuff is.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 May 2016 17:32:01 -0700

> have both ends arguing about how OK stuff is.

I have a mixed reaction.

Simplicity is a strong draw, putting me in John's camp.

On the other hand, for purely transactional domains, it could be simpler 
for the recipient to be able to easily find that ARC-ish mechanisms are 
not authorized.

ARC, ultimately, relies on having the receiver trust assertions made by 
the first ARC signer.  Things get easier for the receiver if they see a 
statement by the domain owner saying "don't bother with ARC".

But yeah, it's another bit of mechanism.  So the question is just how 
much meaningful benefit is there likely to be?  I can't answer that.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 10 May 2016 20:45:55 -0400

> On the other hand, for purely transactional domains, it could be simpler for 
> the recipient to be able to easily find that ARC-ish mechanisms are not 
> authorized.

As is invariably the case here, except sometimes.  It is my impression 
that there are forwarders that break DMARC signatures (MS Exchange is 
often cited) even for a message resent to a single address.

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

---

From: Brandon Long <[email-masked]>
Date: Tue, 10 May 2016 20:15:35 -0700

My worry is that if DMARC started as a private mechanism for high value
targets and large msps to collaborate to lower the risk of phishing for
their shared users, and I don't want ARC to be perceived as breaking that.

I don't want MSPs to have to come up with private lists of high value
targets again, or there being yet another policy enforcement standard for
"no, I really mean it this time".

And yes, you're absolutely correct that there is an installed base of poor
forwarders, though I'm not clear if those can be fixed with ARC but not by
actually making forwarding work correctly in the first place.
Theoretically, some appliance or outbound gateway could blindly add an ARC
header to resolve it, I guess, or a pair of inbound/outbound gateways, to
work around the broken internal server.

Anyways, it's food for thought, especially in regards to how arc and dmarc
intersect.

Brandon

On Tue, May 10, 2016 at 5:45 PM, John R Levine <[email-masked]> wrote:

>> for the recipient to be able to easily find that ARC-ish mechanisms are not
>> authorized.
>>
>
> that there are forwarders that break DMARC signatures (MS Exchange is often
> cited) even for a message resent to a single address.
>
> Regards,
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 May 2016 13:55:00 +0200

It would be silly to deny that ARC is about indirect mail flows.  The reason it
is perceived to be in the wrong camp is that DMARC focuses on originators of
email, while ARC requires no changes for them.  A possible tweak is to
introduce an ARC-0, zero for originator, an optional ARC set with i=0:

ARC-0 is substantially equivalent to a weak signature.  The ARC-Seal field
proves that the originator was involved.  ARC-Message-Signature is expected to
be broken by forwarders.  ARC-Authentication-Results may contain just an auth
stanza, with a possibly redacted authenticated identity.

Malicious self-styled forwarders can abuse ARC-0 in the same manner that they
can abuse weak signatures.  The functional difference w.r.t. conditional
signatures is that the latter require the forwarding "trusted" domain to be
explicitly mentioned by the first signer.  That would increase security if we
could devise methods to avoid being fooled by wannabe phishers who pretend to
be MLMs in order to swindle a conditionally signed message out of our servers.

Formal differences include not requiring a new DKIM version, but requiring a
DMARC authorization for (some forms of) ARC.

ARC-0 is to be added to every submitted message, or limited to addresses
suspected to result in indirect mail flows.  A message signed that way can be
(ab)used to illicitly impersonate an authenticated user of the signing domain.
 Therefore, ARC-0 should only be added by low risk targets.  When such a domain
sees good feedback, it can publish a strict DMARC policy even though its mail
is not purely transactional.

jm2c
Ale

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 11 May 2016 21:33:19 +0900

+1

In practice, after April 2014, nobody who thinks about the issue is
going to take DMARC policies with less than a grain of salt anyway.
Of course they're going to take them *seriously*, but several large
sites were already taking "p=reject" as "strong advice" rather than a
command *before* AOL and Yahoo! started applying p=reject to mail
flows containing millions of non-transactional messages.

ARC is going to get slow uptake anyway, from the point of view of
mailing list owners.  We're going to depend on people trusting our
signature more than Yahoo!'s in any case.

 > statement by the domain owner saying "don't bother with ARC".

Why do you think so?  As far as I can see, you (as receiver) end up in
the same boat as with "p=reject": it's going to be applied to
non-transactional mail flows that your users want to receive, and
you're not going to deny them if you assess that the risk is low based
on other evidence.  An ARC Seal from a site with a high trust level
surely makes a big difference there.

Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 May 2016 07:00:27 -0700

> introduce an ARC-0, zero for originator, an optional ARC set with i=0:

Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a
verification by the originator of its own mail?

> stanza, with a possibly redacted authenticated identity.

Doesn't the i=1 ARC set also prove the originator was involved?

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 May 2016 08:29:18 -0700

> verification by the originator of its own mail?

The concept of an AS[0] set of headers was debated and deemed, as suggested
by Murray, to just be a repetition of the DKIM signature assertion. As
such, it doesn't really add any utility. There have been suggestions on the
arc-discuss list that, perhaps, AS[0] could be used as an assertion "on
behalf of" some other domain that the message submitter was known to the
sending ADMD (as mentioned below under "authenticated identity"). The
biggest problem with that, is whether anyone should trust such purported
authentication claims. I doubt that anyone with minimal exposure to
security issues would find that appealing.

> Doesn't the i=1 ARC set also prove the originator was involved?

Yes, AS[1] testifies to the Authenticated-Results of receiving the message
from the originator.

--Kurt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 May 2016 12:00:25 -0400

I'm pulling the arc-discuss list back off the distribution for this
message (and it's probably a good idea to alert people when you add a
new mailing list to an ongoing discussion).

Kurt's original message asked whether the DMARC working group...

1. ...wants to work on the ARC spec, using
https://datatracker.ietf.org/doc/draft-andersen-arc/ as a starting
point, and

2. ...also wants to work on ARC usage recommendations, using
https://datatracker.ietf.org/doc/draft-jones-arc-usage/ as a starting
point.

It certainly seems that the working group is interested in discussing
ARC, as I can judge from the discussion in the short time since Kurt's
proposal.  So let's go back and get a proper answer:

Does anyone object to having the DMARC working group take on this work?
Does anyone object to using the two documents above as starting points
for that work?
Does anyone have an alternative proposal?

Please respond to this list, <[email-masked]>, by 20 May.

Barry, for the DMARC chairs

On Wed, May 11, 2016 at 11:29 AM, Kurt Andersen (b) <[email-masked]> wrote:
> by Murray, to just be a repetition of the DKIM signature assertion. As such,
> it doesn't really add any utility. There have been suggestions on the
> authentication claims. I doubt that anyone with minimal exposure to security
> issues would find that appealing.
>
>>>

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 May 2016 18:54:19 +0200

On Wed 11/May/2016 17:29:18 +0200 Kurt Andersen (b) wrote:
> On Wed, May 11, 2016 at 7:00 AM, Murray S. Kucherawy wrote:
>> On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote:

[... assume ARC-Seal: i=0 still verifies ...]

>>> ARC-0 is substantially equivalent to a weak signature.  The ARC-Seal
>>> field proves that the originator was involved.  ARC-Message-Signature
>>> is expected to be broken by forwarders.  ARC-Authentication-Results may
>>> contain just an auth stanza, with a possibly redacted authenticated
>>> identity.
>>

No, it doesn't.

> Yes, AS[1] testifies to the Authenticated-Results of receiving the message

That only proves the first receiver was involved.  A final receiver may trust
its results or not.

Ale

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 May 2016 10:09:45 -0700

Removing arc-discuss per suggestion from Barry.

> That only proves the first receiver was involved.  A final receiver may

What would an AS[0] assertion provide that would not be already asserted by
the originator's DKIM-Signature?

If AS[1] is untrustworthy (using the term advisedly), but AS[0] still
verifies, then presumably the original DKIM-Signature would also still
verify and ARC-based information is not needed to have a pass for the DMARC
evaluation.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 May 2016 20:40:06 +0200

On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote:
>>> Yes, AS[1] testifies to the Authenticated-Results of receiving the 
>>> message from the originator.
>>
>> That only proves the first receiver was involved.  A final receiver may 
>> trust its results or not.
> 

Nothing, except that the originator's DKIM-Signature is broken after MLM
processing.  In that respect, ARC-Seal is similar to weak signatures.

> verify and ARC-based information is not needed to have a pass for the DMARC

If the body was altered the original DKIM-Signature is broken.  If AS(0) is
good --which is possible since it didn't sign the body-- and rfc5322.from
matches the AS(0) signer, can we then bypass DMARC validation?  To address
Brandon's concern, high value targets should never produce an AS(0) in the
first place.

Spammers can grab a recent ARC-0 set from any message emitted by a general
purpose domain deploying this technique, let's call it hmail.  Then they craft
a message with:

* the grabbed ARC-0,
* From: [email-masked], and
* ARC set signed by themselves, including faked ARC-Authentication-Results.

W.r.t. what happened before hmail published p=reject, spammers face the
additional difficulty of getting a fresh ARC-0 every day, but hmail know which
messages such ARC-0 was being grabbed from.  Admittedly not much, but maybe can
be improved.

Ale

---

From: "John Levine" <[email-masked]>
Date: 11 May 2016 20:34:39 -0000

>"no, I really mean it this time".

I see your point, but I don't have much hope.  DMARC worked great as a
way to say "I'm a phish target", less great when repurposed to
outsource the pain of some providers' security failures.

No matter what we say, there will always be people who believe that
the strictest possible option is most secure, then blame everyone else
when the predictable screwups happen.  So I don't think you can trust
people's self-assertion of "I really mean it."

Also, keep in mind that DMARC is supposed to be an anti-phishing
technology.  If some nitwit puts a mailing list's address on his
Paypal account or the contact address for ordering some slinky
underwear, and ARC allows the notices to go out through the list, so
what?  It's certainly stupid, it might be embarassing, but nobody's
been phished.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 May 2016 15:28:30 -0700

> >> Doesn't the i=1 ARC set also prove the originator was involved?

Could you say why not?  It seems to me the i=1 ARC set is validating the
message authentication provided by the originator.  That seems to qualify
to me as "involved" on the part of the originator.

> trust

What is the first receiver reporting if not the authentication claims made
by the originator?

Confused,
-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 11 May 2016 22:37:16 +0000

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, May 11, 2016 6:29 PM
To: Alessandro Vesely
Cc: [email-masked]; Kurt Andersen (b); ARC Discussion
Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely <[email-masked]<mailto:[email-masked]>> wrote:

No, it doesn't.

Could you say why not?  It seems to me the i=1 ARC set is validating the message authentication provided by the originator.  That seems to qualify to me as "involved" on the part of the originator.

MH: Is it not possible for i=1 ARC set to forge the “validation” of the message authentication purportedly provided by the purported originator?

What is the first receiver reporting if not the authentication claims made by the originator?

MH: The first receiver is asserting authentication claims by the purported originator. That is not the same thing as validating (verifiable) authentication claims by the originator.
Confused,
-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 May 2016 15:50:40 -0700

Might I suggest that this somewhat lengthy digression from the identified
subject of the thread should move to another thread (unique subject line)?

--Kurt

---

From: Roland Turner <[email-masked]>
Date: Thu, 12 May 2016 10:14:56 +0800

On 05/11/2016 11:29 PM, Kurt Andersen (b) via arc-discuss wrote:

> The concept of an AS[0] set of headers was debated and deemed, as 
> suggested by Murray,

Oh! I've missed this. Did it happen on arc-discuss, or elsewhere? (I've 
not seen it on the list, and a quick scan of Murray's posts in the 
archive turned up nothing.)

> to just be a repetition of the DKIM signature assertion. As such, it 
> doesn't really add any utility.

I disagree. This is comparable to claiming that Arc-Seals generally are 
just repetitions of assertions that could be made with DKIM. In a 
limited sense this is true, but having a well-specified set of rules for 
chaining these assertions appears to be valuable, which is much of the 
rationale for introducing ARC in the first place. The same reasoning 
applies to an assertion by an independent originator.

> There have been suggestions on the arc-discuss list that, perhaps, 
> AS[0] could be used as an assertion "on behalf of" some other domain 
> that the message submitter was known to the sending ADMD

Right, this is the independent origination case (e.g. Gmail "send as my 
work address", ESPs, ...), that is currently glaringly unaddressed.

> (as mentioned below under "authenticated identity"). The biggest 
> problem with that, is whether anyone should trust such purported 
> authentication claims.

Sure, but that's _*exactly*_ the same problem as trusting ARC 
forwarders' claims in the first place. The question that a receiver is 
asking, of every step in the chain (and after verifying the mechanical 
aspects of signature verification) is whether they trust the party whose 
key was used to make the signature to make the assertion that's being made.

Failure to support independent origination explicitly (I've suggested 
cv=I to the same end previously) invites ad hoc arrangements, or simply 
outright false AS[1] assertions. (In the context of establishing 
consensus around a spec, there is a particularly idiotic response to the 
latter action, which is to declare wrong-doing and assume that all such 
messages can be discarded, which ignores a significant fraction of the 
real-world problem that ARC is being developed to address.)

> message from the originator.

That's actually a "no". AS[1] permits a receiver (or other assessor) to 
determine with some confidence that the putative signer made such an 
assertion about the putative originator, it provides no information 
about the involvement of the putative originator except to the extent 
that the assessor additionally trusts the assertions of the putative 
signer. Decisions to trust are necessarily outside the specification. 
This argument applies equivalently to AS[0] independent origination 
scenarios and to AS[>0] forwarding scenarios.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Thu, 12 May 2016 10:19:46 +0800

On 05/12/2016 06:28 AM, Murray S. Kucherawy via arc-discuss wrote:

> Could you say why not?  It seems to me the i=1 ARC set is validating 
> the message authentication provided by the originator.  That seems to 
> qualify to me as "involved" on the part of the originator.

I'd suggest not. AS[1] permits a receiver (or other assessor) to 

> What is the first receiver reporting if not the authentication claims 

They could equally be reporting fraudulent claims in order to defeat 
email security systems at (a) downstream receiver(s).

- Roland

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 12 May 2016 14:47:52 +0900

I believe this thread has moved to "dmarc", so "arc-discuss" has been
removed.

Roland Turner writes:

 > forwarders' claims in the first place.

In a particular formal sense, perhaps.  But an ARC assertion is an
assertion that certain data have been *validated*.  An originator
assertion is an assertion that certain data is *authentic*.  The
assertions are different in *kind*, and therefore the trust decision
is a different problem (requires different data and balances different
risks).  ARC doesn't help with authenticity, as you yourself have been
at pains to explain.  Trying to stretch it to do so is a bad idea (at
least from the point of view of mailing list owners).

 > Failure to support independent origination explicitly (I've
 > suggested cv=I to the same end previously) invites ad hoc
 > arrangements,

That may be true, but IMO it's out of scope for ARC.  It should be
done in DKIM or DMARC.  ARC currently is very easy to interpret: a
third party asserts that it validated some data provided by an earlier
party in the chain (possibly but not always the originator).  Let's
not muddy it with assertions that belong to an originator protocol.

Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 May 2016 14:24:58 -0700

On Wed, May 11, 2016 at 7:19 PM, Roland Turner <[email-masked]>
wrote:

>
> I'd suggest not. AS[1] permits a receiver (or other assessor) to determine
> with some confidence that the putative signer made such an assertion about
> the putative originator, it provides no information about the involvement
> of the putative originator except to the extent that the assessor
> additionally trusts the assertions of the putative signer. Decisions to
> trust are necessarily outside the specification. This argument applies
> equivalently to AS[0] independent origination scenarios and to AS[>0]
> forwarding scenarios.
>

What would an i=0 ARC Set tell you that the i=1 set does not?

As I understand it, an i=0 set would be the author asserting "I validated
my own mail, and it was good."  How would one consume such an assertion in
a meaningful way?

> They could equally be reporting fraudulent claims in order to defeat email
> security systems at (a) downstream receiver(s).
>

...meaning nodes 0 (originator) and 1 are in collusion?  Sure, that's
possible, but how would requiring an i=0 thwart such an arrangement?

-MSK

---

From: Roland Turner <[email-masked]>
Date: Sun, 15 May 2016 22:41:27 +0800

On 05/13/2016 05:24 AM, Murray S. Kucherawy wrote:

> On Wed, May 11, 2016 at 7:19 PM, Roland Turner 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     determine with some confidence that the putative signer made such
>     an assertion about the putative originator, it provides no
>     information about the involvement of the putative originator
>     except to the extent that the assessor additionally trusts the
>     assertions of the putative signer. Decisions to trust are
>     necessarily outside the specification. This argument applies
>     equivalently to AS[0] independent origination scenarios and to
>     AS[>0] forwarding scenarios.
>
>
> As I understand it, an i=0 set would be the author asserting "I 
> validated my own mail, and it was good."  How would one consume such 
> an assertion in a meaningful way?

(Note that during writing the following, my stance has changed. I'd now 
recommend the registration of a new 7601.Method instead of specifying a 
special interpretation for AS[0].)

In the specific case which I see as relevant - that of third-party 
origination - an i=0 set would be a 5598.Originator asserting that it 
had a good faith belief that it was acting on behalf of an Author who 
has legitimate use of the domain-name/email-address, despite the fact 
that no available Method can be used to substantiate that claim. Typical 
cases for this good faith to belief to arise would include at least:

  * ESPs acting on behalf of [typically] smaller customers who haven't
    gotten their SPF include: and/or DKIM CNAMEs created correctly, and
  * webmail services sending with an email address in another domain
    that a user has claimed and demonstrated control of (or at least the
    ability to receive messages at).

For a receiver, the ability to tell the difference between:

  * "we're forwarding this message that we think is probably OK,
    although we received it via SMTP and it passed no authentication
    mechanisms", and
  * "we originated this message on behalf of a customer or user with a
    good faith belief that their use of the domain-name/email-address is
    legitimate"

would be useful in cases where (and while) the receiver trusted the 
Originator's practices in this respect, particularly where a statistical 
model was otherwise flagging the message as borderline.

It might reasonably be objected that a DKIM signature by the Originator 
alone would achieve the same result, however 7601 2.7.1 makes clear that 
DKIM passes need only be reported in Authentication-Results: headers 
(and therefore only appear in ARC-Authentication-Results headers) where 
they are acceptable to the reporting ADMD, and specifically offers as an 
example the case where

    "an ADMD policy might require that the signature(s) on the message
    be added using the DNS domain present in the From header field of
    the message, thus making third-party signatures unacceptable even if
    they verify",

meaning that a third-party Originator cannot rely upon an ARC-signing 
forwarder to convey this information. As a practical matter, an 
ARC-signing forwarder could also throw away the existing chain and start 
a new one if it wished, however this is not an expected mode of 
operation, while DKIM validators being choosy about what they validate 
and/or report certainly is.

An interesting alternative would be to amend 7601 to require the 
reporting of all DKIM results and to disregard the fact that some DKIM 
implementations simply won't, although this does not seem ideal.

It occurs to me while writing that an additional Method could be 
registered for third-party Originators to explicitly assert (a) that 
they're originating on behalf of the putative Author, and (b) that 
they've authenticated the Author by some prior means. This would appear 
to be the essence of the capability that I'm advocating: a standardised 
means of making this claim in a form that receivers can recognise 
explicitly as being different from a typical forwarding case and 
therefore to potentially draw different assumptions. This approach would 
not require AS[0], it would simply use AS[1] and cause the assertion to 
appear in AAR[1]. Pending the registration of a new Method, this could 
simply be a comment on the "none" result:

     From: User <[email-masked]>
     ARC-Authentication-Results: i=1; webmail.example; none (sent by 
webmail.example on behalf of [email-masked])

or

     From: Company <[email-masked]>
     ARC-Authentication-Results: i=1; esp.example; none (sent by 
esp.example on behalf of customer.example)

(some creative abuse of vbr and auth results would work, but wouldn't 
quite convey the intended information).

The approach that I had suggested earlier (cv=I) now appears to me to 
overload the cv field and, as above, I now view a specific 7601.Method 
as a better option than a special interpretation for AS[0].

- Roland

>     They could equally be reporting fraudulent claims in order to
>     defeat email security systems at (a) downstream receiver(s).
>
>

---

From: Roland Turner <[email-masked]>
Date: Sun, 15 May 2016 22:48:34 +0800

> I believe this thread has moved to "dmarc", so "arc-discuss" has been

Thanks. It appears that I was not on dmarc (now corrected), so had 
missed quite a bit of the discussion.

> least from the point of view of mailing list owners).

Thanks for persisting on this. Per my earlier email to Murray, I now 
agree with you. The sensible thing to do would appear to be to register 
a new 7601.Method to describe situations where a 5598.Originator wishes 
to explicitly assert that they're acting on behalf of an Author from a 
different ADMD whom they've previously authenticated by some other means.

> not muddy it with assertions that belong to an originator protocol.

I'd suggest that the areas of concern (webmail providing the ability for 
someone to send with the From: address of their work account that 
they've previously demonstrated control of, [typically] small customers 
of ESPs who haven't got their DKIM etc. sorted out) aren't well 
addressed by DKIM or DMARC, but that there's also a better option than 
AS[0].

- Roland

---

From: Roland Turner <[email-masked]>
Date: Sun, 15 May 2016 22:55:04 +0800

(Sorry Murray, I missed the tail of your message.)

No, "they" meaning the i=1 party. Having a third-party originator state 
their own assertions in a form that ARC will include in its chain allows 
the receiver to make decisions based upon the trust of the i=0 party, 
even where they don't trust the i=1 party.

Also, no requirement, just an option for Originators. Per my earlier 
message though, I'd now suggest that this is a job for a new 7601.Method.

- Roland

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 May 2016 01:44:56 -0400

> Barry, for the DMARC chairs

Barry, I believe the IETF should offer an simplified Policy Lookup 
alternative for 3rd party authorization.  It should be a "product 
option" for implementators of any size.

I think the ARC framework attempts to achieve the same end result at a 
very more complex, higher cost design approach. I don't opposed any 
further development, however, technical alternatives should be offered.

I could reintroduce a modified DSAP (DKIM Signature Authorization 
Protocol) proposal that would piggy back off the DMARC protocol.

I could consolidate ADSP/ATPS and wrap it over DMARC.

I think the IETF should offer simplified alternatives using the 
original proof of concept "Policy DNS lookup" models.  DMARC now 
replaced ADSP - a policy lookup solution.  It just needs to be further 
developed with 3rd party extensions.  That could include ARC as well.

Thanks

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 May 2016 17:08:13 +0200

> Does anyone object to using the two documents above as starting points

ARC, as currently documented and conceived, aims at "a more nuanced
interpretation to guide any local policies related to messages that arrive with
broken domain authentication (DMARC)."  It does not propose any DMARC
improvement, let alone phase 2 milestone.

Unless ARC commits to a purpose congenial with DMARC's charter, I'd find it
objectionable for this WG to take on its work.

> Does anyone have an alternative proposal?

The "least broken" proposal for phase 2 seems to be dkim-conditional.  It
emerged as an originator protocol, so it can develop without muddying ARC.

> Please respond to this list, <[email-masked]>, by 20 May.

On it, but I doubt ARC consensus will be apparent by that date.

Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 May 2016 12:53:06 -0700

> > Does anyone object to having the DMARC working group take on this work?

I agree with Alessandro, but for procedural reasons: I'm not sure it fits
within our present charter.

The charter enumerates three tracks, the first of which appears to allow
discussion of new protocols; in particular, one might argue that ARC is a
"form of DKIM signature that is better able to survive transit through
intermediaries".  However, in the second track, it says "The working group
will not develop additional mail authentication technologies, but may
document authentication requirements that are desirable", and there are
chunks of ARC that are clearly new.  (Having now implemented ARC, I can
attest that there was enough new code needed that I would call it "new".)

Absent a desire to form a distinct working group to develop ARC, I think we
need to discuss rechartering before we can entertain this motion.

> Does anyone object to using the two documents above as starting points

Modulo the first question, no.

> improvement, let alone phase 2 milestone.

It proposes to provide a new authentication method that can more accurately
reflect the "true" (for some value thereof) authenticity of a message,
allowing DMARC to behave more accurately.  How is that not an improvement?
DMARC was meant to be extensible to better authentication methods as they
appear, and this is an instance of such.

> emerged as an originator protocol, so it can develop without muddying ARC.

I have an unreleased implementation of that.  It also more easily qualifies
under our charter, IMHO.  I think we should at least allow discussion of
that one.

-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 17 May 2016 20:14:17 +0000

Comments in-line

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 17, 2016 3:53 PM
To: Alessandro Vesely
Cc: Kurt Andersen (b); DMARC; Barry Leiba
Subject: [!!Mass Mail]Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

> Does anyone object to having the DMARC working group take on this work?

I agree with Alessandro, but for procedural reasons: I'm not sure it fits within our present charter.

The charter enumerates three tracks, the first of which appears to allow discussion of new protocols; in particular, one might argue that ARC is a "form of DKIM signature that is better able to survive transit through intermediaries".  However, in the second track, it says "The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable", and there are chunks of ARC that are clearly new.  (Having now implemented ARC, I can attest that there was enough new code needed that I would call it "new".)
MH: To the extent that ARC informs local policy under DMARC, I support the group taking it on. My personal stance is that p=reject means just that but I recognize that there are folks who can’t get control of their mail streams or there are corner cases such as mailing lists which for historical reasons do not wish to change how they function.
Absent a desire to form a distinct working group to develop ARC, I think we need to discuss rechartering before we can entertain this motion.

MH: If we need to re-charter then I think we should re-charter. There are already implementations of ARC and there appears to be sufficient support to justify the effort.

MH: +1

It proposes to provide a new authentication method that can more accurately reflect the "true" (for some value thereof) authenticity of a message, allowing DMARC to behave more accurately.  How is that not an improvement?  DMARC was meant to be extensible to better authentication methods as they appear, and this is an instance of such.

MH: This is not an extension of DMARC itself. It leverages a DKIM like signing approach to provide additional data points to validators wishing to implement local policy in a more informed manner. This is a nuanced but important difference unless someone is suggesting munging ARC into DMARC itself.

I have an unreleased implementation of that.  It also more easily qualifies under our charter, IMHO.  I think we should at least allow discussion of that one.
MH: I thought running code was one of the criteria. Dkim-conditional never got significant support. I’m not against it per se but unless there is a compelling reason I prefer to avoid re-visiting old ground.
Mike

---

From: Steven M Jones <[email-masked]>
Date: Tue, 17 May 2016 13:43:20 -0700

On 05/17/2016 12:53, Murray S. Kucherawy wrote:
> discussion of new protocols; in particular, one might argue that ARC is
> a "form of DKIM signature that is better able to survive transit through
> intermediaries".  However, in the second track, it says "The working
> group will not develop additional mail authentication technologies, but
> may document authentication requirements that are desirable", and there
> are chunks of ARC that are clearly new.  (Having now implemented ARC, I
> can attest that there was enough new code needed that I would call it
> "new".)

Seems to me you've identified a contradiction in the charter, rather
than an objection to developing ARC...

> I have an unreleased implementation of that.  It also more easily
> qualifies under our charter, IMHO.  I think we should at least allow
> discussion of that one.

Why wouldn't we discuss that, or other proposals?

--S.

---

From: Steven M Jones <[email-masked]>
Date: Tue, 17 May 2016 13:47:17 -0700

On 05/17/2016 13:14, MH Michael Hammer (5304) wrote:
> 
> MK: Absent a desire to form a distinct working group to develop ARC, I think
> we need to discuss rechartering before we can entertain this motion.
> 
> MH: If we need to re-charter then I think we should re-charter. There
> are already implementations of ARC and there appears to be sufficient
> support to justify the effort.

I've had discussions with a few folks, and nobody seemed to think this
was outside the existing charter. I hope they'll speak up if they still
see things the same way...

> MH: This is not an extension of DMARC itself. It leverages a DKIM like
> signing approach to provide additional data points to validators wishing
> to implement local policy in a more informed manner. This is a nuanced
> but important difference unless someone is suggesting munging ARC into
> DMARC itself.

If ARC is approached as a standalone protocol, incorporating support for
it into DMARC still involves changes to the DMARC specification at some
point. For example, the ARC spec suggests concrete changes to the DMARC
aggregate report's local_policy section. If that change in and of itself
isn't worthy of work, do we need a clearer extension mechanism?

> MK: I have an unreleased implementation of that.  It also more easily
> MH: I thought running code was one of the criteria. Dkim-conditional
> never got significant support. I’m not against it per se but unless
> there is a compelling reason I prefer to avoid re-visiting old ground.

I have no objection to conditional signatures per se, and it seems
appropriate to have a discussion of the merits.

And I will refrain from starting that discussion now... ;)

--S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 May 2016 17:46:04 -0700

On 5/17/2016 12:53 PM, Murray S. Kucherawy wrote:
> he charter enumerates three tracks, the first of which appears to allow
> Absent a desire to form a distinct working group to develop ARC, I think

I don't.

Relevant charter text:

>> The working group will explore possible updates and extensions to the
>> specifications in order to address limitations and/or add
>> capabilities.
> ...
>> Specifications produced by the working group
> ...
>>  1. Addressing the issues with indirect mail flows
>>
>> The working group will specify mechanisms for reducing or eliminating
>> the DMARC's effects on indirect mail flows, including deployed
>> behaviors of many different intermediaries, such as mailing list
>> managers, automated mailbox forwarding services, and MTAs that
>> perform enhanced message handling that results in message
>> modification. Among the choices for addressing these issues are:
>>
>> - A form of DKIM signature that is better able to survive transit
>> through intermediaries.
>>
>> - Collaborative or passive transitive mechanisms that enable an
>> intermediary to participate in the trust sequence, propagating
>> authentication directly or reporting its results.
>
> as against:
>
>>  2. Reviewing and improving the base DMARC specification
>>
>> The working group will not develop additional mail authentication
>> technologies, but may document authentication requirements that are
>> desirable.

Any interesting topic produces real challenges in charter-writing and 
even more challenges in charter-reading.

However I read Item 1 as exactly matching the issue at hand and I read 
that text as being unambiguously perfect for the specific proposal at 
hand.  (Hint:  this was not an accident.)

The current topic has nothing to do with Item 2, which is where the 
constraint is placed. So the constraint is not relevant for the current 
topic.

Yes, one certainly could wish for better writing.  Sorry about that. 
But really...

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 May 2016 17:57:16 -0700

> than an objection to developing ARC...
...and I thought that's how I'd characterized it.  But if the charter says
we can't take on this work, or is ambiguous on that point, I think our
process dictates we have to sort that out.

I don't think I made any comment resembling "We shouldn't talk about ARC
here."

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 May 2016 18:08:33 -0700

On Tue, May 17, 2016 at 5:46 PM, Dave Crocker <[email-masked]> wrote:

> Any interesting topic produces real challenges in charter-writing and even
> more challenges in charter-reading.
>

Indeed, I've yet to encounter a perfect charter.

> constraint is placed. So the constraint is not relevant for the current

That feels like a convenient interpretation to me, for two reasons:

1) It feels like a bit of a stretch to call ARC "a form of DKIM signature",
so I have to assume ARC falls under the second bullet.

2) The section of the charter you cite enumerates three "tracks', which it
later calls "phases".  If we're done with the first phase by sending our
sole document to the IESG (which has happened, and the chairs have
explicitly declared phase one done), then we appear to have entered a phase
for which the charter proscribes things like ARC.

> Yes, one certainly could wish for better writing.  Sorry about that. But
> really...

I'm not opposed to developing ARC within this WG or even within the IETF.
I just want to make sure we're following our own rules here, and that
someone who later decides he hates ARC has no basis to appeal.  If this
needs fixing, let's fix it.  If nobody really cares, let's move on.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 May 2016 18:15:50 -0700

On 5/17/2016 6:08 PM, Murray S. Kucherawy wrote:
> On Tue, May 17, 2016 at 5:46 PM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Relevant charter text:
>
>     Any interesting topic produces real challenges in charter-writing
>     and even more challenges in charter-reading.
>
>
>     However I read Item 1 as exactly matching the issue at hand and I
>     read that text as being unambiguously perfect for the specific
>     proposal at hand.  (Hint:  this was not an accident.)
>
>     constraint is placed. So the constraint is not relevant for the
>     current topic.
>
>
> 1) It feels like a bit of a stretch to call ARC "a form of DKIM
> signature", so I have to assume ARC falls under the second bullet.

You seem to have missed the second sub-bullet under Item 1:

> Collaborative or passive transitive mechanisms that enable an

That exactly describes ARC.  (Did I mention that that wasn't an accident?)

> I'm not opposed to developing ARC within this WG or even within the
> IETF.  I just want to make sure we're following our own rules here, and
> that someone who later decides he hates ARC has no basis to appeal.  If
> this needs fixing, let's fix it.  If nobody really cares, let's move on.

I get that the issue being raised here is purely procedural and that 
there is no intended (or even actual) resistance to doing the work.

My point is that the points I'm explaining afford a careful reading of 
the charter and that it shows that the charter /already/ fully covers 
the proposed work.  And not as a stretch.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 May 2016 21:52:55 -0700

> You seem to have missed the second sub-bullet under Item 1:

I assure you I didn't.  I even said, clearly I thought:  "...so I have to
assume ARC falls under the second bullet."

> That exactly describes ARC.  (Did I mention that that wasn't an accident?)

And I agree, but then I also mentioned that we're now operating under the
second phase of the charter, or so the chairs seemed to indicate explicitly
with their "phase 1 is done" message.  This citation is in the first; the
proscription against "additional mail authentication technologies" (which
also, by the way, exactly describes ARC) that I'm worried about is in the
second.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 May 2016 22:23:10 -0700

> also, by the way, exactly describes ARC) that I'm worried about is in the

Reducing this to my basic issue, setting aside the matter of phases:

There's one clause in the charter that says ARC is fine, and one that
proscribes it.  You appear to be claiming that the first one wins over the
second, plain and simple.  I don't understand why it's plain and simple.
Why do they not have equal effect?  Is there some "default allow" nuance
when interpreting ambiguous charters?

-MSK

---

From: Roland Turner <[email-masked]>
Date: Wed, 18 May 2016 13:58:46 +0800

On 05/18/2016 01:23 PM, Murray S. Kucherawy wrote:

> On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     And I agree, but then I also mentioned that we're now operating
>     under the second phase of the charter, or so the chairs seemed to
>     indicate explicitly with their "phase 1 is done" message. This
>     citation is in the first; the proscription against "additional
>     mail authentication technologies" (which also, by the way, exactly
>     describes ARC) that I'm worried about is in the second.
>
>
> proscribes it.  You appear to be claiming that the first one wins over 
> the second, plain and simple.  I don't understand why it's plain and 
> simple.  Why do they not have equal effect?  Is there some "default 
> allow" nuance when interpreting ambiguous charters?

Weighing into a conversation that I only half understand, the charter 
<https://datatracker.ietf.org/wg/dmarc/charter/> appears to talk about 3 
separate Tracks, the apparent implication being that any work item for 
this WG needs to be in scope for at least one of those Tracks, not that 
a work item needs to fit into all of them; I would suggest that applying 
the latter interpretation would (a) contradict the plain language of the 
charter, and (b) disqualify almost all work items that the WG might 
consider. As ARC fits squarely into scope for Track 1, the fact that it 
has characteristics which preclude its being in scope for Track 2 does 
not by itself put it out of scope for this WG. There is no contradiction 
here.

Separately, the WG's work has been divided into three phases which, 
although not explained, align approximately with one track each and 
appear to have been set up to focus the WG's efforts sequentially on one 
item at a time with a view to actually getting deliverables delivered. 
This gives rise to the observation that ARC is in scope for Phase I but 
not in scope for Phase II. So far so good, except that Phase I is 
currently considered to be complete, meaning that ARC is not in scope 
for the current or remaining Phases, despite it being in scope for the 
WG. The good news is that reopening a Phase does not require 
re-chartering, just consensus of the WG, which is presumably the reason 
for Barry's question. The dilemma would appear to be that reopening 
Phases willy-nilly would risk slowing the WG's progress still further, 
while slavishly sticking to the plan would exclude work on a very 
worthwhile mechanism which (a) came into being after the charter was 
written, (b) is a near perfect match for one of the Phase I proposed 
items, and (c) provides worthwhile capabilities for that proposed item 
that no other mechanism addressed in Phase I provides.

My view is that ARC is a sufficiently compelling addition that reopening 
Phase I is warranted.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Wed, 18 May 2016 14:00:27 +0800

> Does anyone object to using the two documents above as starting points

I do not object to either of things; in fact I support both.

- Roland

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 May 2016 06:41:16 -0700

On 5/17/2016 10:23 PM, Murray S. Kucherawy wrote:
>     citation is in the first; the proscription against "additional mail
>     authentication technologies" (which also, by the way, exactly

Murray,

There are a few different points here:

> 1. Addressing the issues with indirect mail flows

If anyone disagrees with that, that should probably be discussed as a 
distinct point, because I think it's obvious.

2.  The constraint to "not develop additional mail authentication
technologies" has a scope limited to the second "track", which is:

> Reviewing and improving the base DMARC specification

Since the proposed activity does not directly touch any aspect of the 
base DMARC specification, I again think that the INapplicability of the 
text for track 2 is also obvious.

3. Now we get to the difference between a track and a phase.  And to 
state the issue is to state its resolution:  these are different 
constructs, with different terminology.  As if they are meant to be 
considered separately...

The first item in Phase II is:

>  Phase II:
>
> Specification of DMARC improvements to support indirect mail flows

And here's where I wish we'd phrased things a bit differently, although 
I don't think the current wording is a show-stopper.

The proposed work falls under this first item in phase II.

The catch is that the draft doesn't /say/ it's improving DMARC.  (In 
fact, I've been quite vigorous in pressing to have the proposed spec 
carefully not say much about DMARC.)  But really that's a 
document-writing point, not a working group functional point.

That is, ARC's development has been specifically motivated to respond to 
exactly this item in Phase II.

If we did sloppy specification-writing, we'd have written this as a part 
of a DMARC enhancement.  Not the 'base', of course, but an enhancement. 
The fact that it's been written as an independent component is so that 
its use is not /limited/ to DMARC.  But again, that's merely a writing 
artifact.

So, my reading of the charter says that the proposed spec falls under 
the first item of Phase two and the second sub-bullet of Track 1.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Wed, 18 May 2016 07:06:36 -0700 (PDT)

> distinct point, because I think it's obvious.

I concur.

> text for track 2 is also obvious.

Agreed again.

> constructs, with different terminology.  As if they are meant to be

It never occured to me to think of the two as connected or cooresponding
or anything similar.

> I don't think the current wording is a show-stopper.

It probably would have help to clearly link this item to track 1.

> document-writing point, not a working group functional point.

Agreed.

> the first item of Phase two and the second sub-bullet of Track 1.

As does my own reading.

				Ned