[dmarc-ietf] Other potential work items for the ARC spec

2016-05-12 Thread Kurt Andersen (b)
Allessandro Veseley had suggested (on the arc-discuss) list that the
semantics and construction of the ARC sets could be defined in a
generalized DKIM-like recipe.

When I had discussed this with Dave Crocker, he pointed out that such an
idea would align with the (never quite finalized) DOSETA (
https://datatracker.ietf.org/doc/draft-crocker-doseta-base/) idea and that
having both ARC and DKIM as potential instantiations of the abstract
concept could be enough to bring DOSETA to realization.

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

2016-05-12 Thread Murray S. Kucherawy
On Wed, May 11, 2016 at 7:19 PM, Roland Turner 
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?


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

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

2016-05-12 Thread Alessandro Vesely
On Wed 11/May/2016 22:35:29 +0200 Kurt Andersen (b) wrote:
> On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely wrote:
> 
>> 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.

That requirement is not necessarily about AMS(0).  It can be AMS(i), i > 0.
(Indeed, the current spec contemplates i > 0 only.)

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

Yet, I share the feeling which originated this thread, namely that ARC can do
more than validate email address portability (via forwarding) among a private
group of huge mailbox providers.

If a single solution can be used for both solving DMARC's indirect mail flows
problem and participating in safe forwarding, that can make life easier for
mail system maintainers.

Ale

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