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

[Barry Leiba]

>> . . . the work is accepted, and the starting-point documents
>> will become working group documents.
>>
>> Please submit new versions of those documents with working group file
>> names, as follows:. . .

>> Great; then the work is accepted, and the starting-point documents
>> will become working group documents.
>>
>> Please submit new versions of those documents with working group file
>> names, as follows:
>>
>> draft-andersen-arc -> draft-ietf-dmarc-arc-protocol-00
>>
>> draft-jones-arc-usage -> draft-ietf-dmarc-arc-usage-00
>>
>> When you submit them, please be sure to fill in the "replaces" field
>> on the second page of the submission form with the old file name.
>
>
> Will do! Probably later this week.

...which is now two weeks ago.

New versions soon?

Barry

___
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 Tue, Jun 7, 2016 at 7:06 AM, Barry Leiba  wrote:

> . . . the work is accepted, and the starting-point documents
> will become working group documents.
>
> Please submit new versions of those documents with working group file
> names, as follows:. . .
>

Will do! Probably later this week.

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

[Barry Leiba]

>> Murray, I've seen no response to Ned's note (which I agree with) that
>> explains why we think the charter, as written, covers the ARC work.
>> Do you have any follow-up, or did Ned's message address your concern?
>
> I think we can call it "addressed" by me accepting that I'm in the rough in
> terms of consensus.  If my interpretation is singular, there's no need to
> dwell on it.

Great; then the work is accepted, and the starting-point documents
will become working group documents.

Please submit new versions of those documents with working group file
names, as follows:

draft-andersen-arc -> draft-ietf-dmarc-arc-protocol-00

draft-jones-arc-usage -> draft-ietf-dmarc-arc-usage-00

When you submit them, please be sure to fill in the "replaces" field
on the second page of the submission form with the old file name.

Barry

___
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 Fri, Jun 3, 2016 at 8:24 AM, Barry Leiba  wrote:

> Murray, I've seen no response to Ned's note (which I agree with) that
> explains why we think the charter, as written, covers the ARC work.
> Do you have any follow-up, or did Ned's message address your concern?


I think we can call it "addressed" by me accepting that I'm in the rough in
terms of consensus.  If my interpretation is singular, there's no need to
dwell on it.

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

[Barry Leiba]

I hear that some people would like to consider other things besides
ARC, and that's noted.  The working group clearly does seem to want to
work on ARC and to start with Kurt's draft in that endeavour.

Murray, I've seen no response to Ned's note (which I agree with) that
explains why we think the charter, as written, covers the ARC work.
Do you have any follow-up, or did Ned's message address your concern?

Barry

On Wed, May 18, 2016 at 10:06 AM,   wrote:
>> There are a few different points here:
>
>
>> 1.  The proposed activity falls perfectly under "track" 1:
>
>
>> > 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.
>
>
> I concur.
>
>> 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.
>
>
> Agreed again.
>
>> 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...
>
>
> It never occured to me to think of the two as connected or cooresponding
> or anything similar.
>
>
>> 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.
>
>
> It probably would have help to clearly link this item to track 1.
>
>> 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.
>
>
> Agreed.
>
>> 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.
>
>
> As does my own reading.
>
> Ned
>
>
> ___
> 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)

[ned+dmarc]

There are a few different points here:



1.  The proposed activity falls perfectly under "track" 1:



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


I concur.


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.


Agreed again.


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


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



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.


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


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.


Agreed.


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.


As does my own reading.

Ned

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

[Dave Crocker]

On 5/17/2016 10:23 PM, Murray S. Kucherawy wrote:

On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy
mailto:superu...@gmail.com>> 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.


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?



Murray,

There are a few different points here:

1.  The proposed activity falls perfectly under "track" 1:


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
  Brandenburg InternetWorking
  bbiw.net

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

[Roland Turner]

On Wed 11/May/2016 18:00:25 +0200 Barry Leiba wrote:


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?


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

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

[Roland Turner]

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

On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy 
mailto:superu...@gmail.com>> 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.


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?


Weighing into a conversation that I only half understand, the 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
___
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 Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy 
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.
>

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
___
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 Tue, May 17, 2016 at 6:15 PM, Dave Crocker  wrote:

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

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


> Collaborative or passive transitive mechanisms that enable an
>> intermediary to participate in the trust sequence, propagating
>> authentication directly or reporting its results.
>>
>
> 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
___
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)

[Dave Crocker]

On 5/17/2016 6:08 PM, Murray S. Kucherawy wrote:

On Tue, May 17, 2016 at 5:46 PM, Dave Crocker mailto:dcroc...@gmail.com>> wrote:


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.


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


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.


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.


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


Collaborative or passive transitive mechanisms that enable an
intermediary to participate in the trust sequence, propagating
authentication directly or reporting its results.


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
  Brandenburg InternetWorking
  bbiw.net

___
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 Tue, May 17, 2016 at 5:46 PM, Dave Crocker  wrote:


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

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


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

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
___
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 Tue, May 17, 2016 at 1:43 PM, Steven M Jones  wrote:

>
> Seems to me you've identified a contradiction in the charter, rather
> 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
___
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)

[Dave Crocker]

On 5/17/2016 12:53 PM, Murray S. Kucherawy wrote:

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


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
  Brandenburg InternetWorking
  bbiw.net

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

[Steven M Jones]

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

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.

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

[Steven M Jones]

On 05/17/2016 12:53, Murray S. Kucherawy wrote:
> 
> 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".)

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.

___
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 Tue, May 17, 2016 at 8:08 AM, Alessandro Vesely  wrote:

> > 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
> > for that work?
>

Modulo the first question, no.


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

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.


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

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
___
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 18:00:25 +0200 Barry Leiba wrote:
> 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?

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

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

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)

[Hector Santos]

On 5/11/2016 12:00 PM, Barry Leiba wrote:

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


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


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

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

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

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

[John R Levine]

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

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

[Dave Crocker]

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.


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
  Brandenburg InternetWorking
  bbiw.net

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

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

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)

[Dave Crocker]

On 5/10/2016 11:08 AM, Steven M Jones wrote:

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.



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

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

[Steven M Jones]

On 05/10/2016 10:23, Kurt Andersen (b) wrote:
> 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)  > wrote:
>
> On Thu, May 5, 2016 at 6:54 AM, Tim Draegen  > 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.
>

+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: s...@dmarc.org, s...@crash.com



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