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

[Dave Crocker]

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

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.


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 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] [!!Mass Mail]Re: Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

[MH Michael Hammer (5304)]

Comments in-line

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

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".)
MH: To the extent that ARC informs local policy under DMARC, I support the 
group taking it on. My personal stance is that p=reject means just that but I 
recognize that there are folks who can’t get control of their mail streams or 
there are corner cases such as mailing lists which for historical reasons do 
not wish to change how they function.
Absent a desire to form a distinct working group to develop ARC, I think we 
need to discuss rechartering before we can entertain this motion.

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

> Does anyone object to using the two documents above as starting points
> for that work?

Modulo the first question, no.

MH: +1


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.

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.

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.
MH: I thought running code was one of the criteria. Dkim-conditional never got 
significant support. I’m not against it per se but unless there is a compelling 
reason I prefer to avoid re-visiting old ground.
Mike
___
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