[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

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

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

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

[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