[dmarc-ietf] Independent origination and AS[0]

[Stephen J. Turnbull]

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

Roland Turner writes:

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

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

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

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

[Roland Turner]

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

On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely > wrote:



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

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.


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.



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


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


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


- Roland

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

[dmarc-ietf] Independent origination and AS[0] (Re: [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone))

[Roland Turner]

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




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.


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

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

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

[Kurt Andersen (b)]

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

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

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

[MH Michael Hammer (5304)]

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, May 11, 2016 6:29 PM
To: Alessandro Vesely
Cc: dmarc@ietf.org; 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 
mailto:ves...@tana.it>> 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.
>>
>> Doesn't the i=1 ARC set also prove the originator was involved?

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?


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

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

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

[Murray S. Kucherawy]

On Wed, May 11, 2016 at 9:54 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.
> >>
> >> Doesn't the i=1 ARC set also prove the originator was involved?
>
> 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.


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

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

Confused,
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Document shepard's review of draft-ietf-dmarc-interoperability-14

[ned+dmarc]

In my capacity as document shepard, I've now done fairly careful review of the
document. The results of that review are attached below.

Almost all - but not all - of the issues I found were editorial, not technical,
in nature, which is as it should be for a document that this stage. However, we
are also about to issue an IETF-wide last call, which will hopefully result in
wider review of the document by a more general audience, so now is also the
time to correct as many editorial nits as we can so the document is as clear as
it can be.

For this reason I think it would be a good idea to address these nits sooner
rather than later. But if that's a problem I certainly can live with
going to last call with the current version.

Ned
First, some global changes need to be made to be consistent with RFC 5598:

  "RFC5321.mailfrom" -> "RFC5321.MailFrom" 
  
  "RFC5321.HELO/EHLO" -> "RFC5321.HELO/.EHLO" 

  "RFC5321.Helo" -> "RFC5321.HELO/.EHLO"
  
  "RFC5322.from" -> "RFC5322.From" 

I note that RFC5322.Foo usage other than RFC5322.from appears to be correct. 

I will add that I take no position on the style chosen in RFC 5598, in
particular the RFC5321.HELO/.EHLO form. But if we're going to use RFC 5598
conventions we need to be consistent with them.

The document variously, and more or less interchangeably, uses the terms

   "bounce" message
   
and 

   delivery status notification
   
to refer to messages with a null RFC5322.MailFrom. Neither term is ideal;
"bounce" message is too informal and potentially covers messages with
non-NULL RFC5322.MailFrom, and both terms are insufficiently general.

The term RFC 5321 uses is "notification message", but only in a narrow
context. I therefore suggest defining this term in the conventions section
as follows:

   The term "notification message" (RFC 5321 section 4.5.5) is used to refer
   a message with a null RFC5321.MailFrom.
   
And then use this term throughout the document whereever it currently
says "bounce" message or delivery status notification.

The Introduction ends with:

   Also, some practices which are in use at the time of this document
   may or may not be "best practices" as future standards evolve.

This statement doesn't seem to connect with anything. Is this talking
about practices described in this document? It so, it should be changed
to something like:

   Note that some practices described in this document and presently in use
   may or may not be "best practices", especially as future standards evolve.

Or perhaps drop the statement completely. (It's axiomatic that best practices
are going to change over time.)

In 1.1 Document Conventions:

   Notation regarding structured fields is taken from [RFC5598].
  
   Organizational Domain and Authenticated Identifiers are specified in
   DMARC [RFC7489].

The first is a sentence fragment and both are incomplete. How about:

   The notation used to document references structured fields is defined in
   [RFC5598] section 1.3.

   The terms "Organizational Domain" and "Authenticated Identifier" are
   specified in DMARC [RFC7489] section 3.

There probably should be a paragraph break before the last sentence in
section 2.

The first paragraph in section 2.1 says:

   The identifiers which are used by DKIM and SPF are technical components of
   the transport process for SMTP.

This is true of SPF, which uses RFC5321.mailfrom and RFC5321.HELO/HELO. But
DKIM doesn't really take identifiers from the message and certainly not from
the SMTP transport layer.

I'm not entirely sure how to fix this since I'm not sure what this note is
trying to say. The obviou thing to do is simply remove the reference to DKIM
entirely.

The last sentence of section 2.1 says:

   The mitigations described in this document generally require the relaxed
   mode of Identifier Alignment.

Maybe I'm missing something, but I don't think this is true - in fact from what
I can tell few if any of the mitigations absolutely require relaxed mode. I
suggest changing this to read:

   Some of the mitigations described in this document only work with the
   relaxed mode of Identifier Alignment.

In section 2.1.1 we need to clarify whether "multiple DKIM signatures"
refers to multiple signatures for the same domain, multiple signatures for
different domains, or both. (Since I don't know the state of interoperability
here I can't answer this question.)

Section 2.2, second paragraph:

   "forwarding behavior involves" -> "forwarding operations involve"

In section 2.3, third paragraph the document states:

   The latter allows
   for trivial modifications (largely regarding whitespace and folding)
   that maintain the integrity of the content of the email. 

The wording here is awkward, but more to the point, this ignores space
adjustment attacks on the message body, per RFC 6376 section 8.1. I suggest
changing this to something like:

   The latter is designed to accomodate trivial modifications to whites

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

[Kurt Andersen (b)]

On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely  wrote:

> On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote:
> >
> > What would an AS[0] assertion provide that would not be already asserted
> by
> > the originator's DKIM-Signature?
>
> Nothing, except that the originator's DKIM-Signature is broken after MLM
> processing.  In that respect, ARC-Seal is similar to weak signatures.
>
> > 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.
>
> 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.
>

AS[0] will not be "good" in the way you propose because nearly all of the
transformations that will break DKIM will also break the AMS
(ARC-Message-Signature) and, per
https://tools.ietf.org/html/draft-andersen-arc-04#section-5.1.1.5 bullet 3,
AMS must pass for the overall ARC set to be considered valid.

I'd like to respectfully suggest that "bypassing DMARC validation" is
pretty far out of scope for what we've intended with ARC.

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

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

[John Levine]

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

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

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

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

[Alessandro Vesely]

On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote:
> Removing arc-discuss per suggestion from Barry.
> 
> On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely  wrote:
>> 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:
>>
>> [... assume ARC-Seal: i=0 still verifies ...]
>>
>>> Doesn't the i=1 ARC set also prove the originator was involved?
>>
>> No, it doesn't.
>>
>>> 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.
> 
> What would an AS[0] assertion provide that would not be already asserted by
> the originator's DKIM-Signature?

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

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

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: user@hmail.example, 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

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

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

[Kurt Andersen (b)]

Removing arc-discuss per suggestion from Barry.

On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely  wrote:

> 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:
>
> [... assume ARC-Seal: i=0 still verifies ...]
>
> > Doesn't the i=1 ARC set also prove the originator was involved?
>
> No, it doesn't.
>
> > 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.
>

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

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

[Alessandro Vesely]

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.
>>
>> Doesn't the i=1 ARC set also prove the originator was involved?

No, it doesn't.

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

Ale

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

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

[Barry Leiba]

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, , by 20 May.

Barry, for the DMARC chairs


On Wed, May 11, 2016 at 11:29 AM, 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:
>>>
>>> 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:
>>
>>
>> Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a
>> 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.
>
>>>
>>> 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.
>>
>>
>> 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
>
>
> ___
> 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

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

[Kurt Andersen (b)]

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:
>
>> 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:
>>
>
> Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a
> 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.


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

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

[Murray S. Kucherawy]

On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely  wrote:

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

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


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

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

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

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

[Stephen J. Turnbull]

Dave Crocker writes:
 > On 5/10/2016 5:23 PM, John Levine wrote:

 > >> Should DMARC add a policy setting for whether the domain owner feels that
 > >> 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.

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

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

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


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

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

[Alessandro Vesely]

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

On Wed 11/May/2016 05:15:35 +0200 Brandon Long wrote:
> 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  wrote:
> 
>> 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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
>> Please consider the environment before reading this e-mail.
>>
>>
>> ___
>> 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
> 

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