Re: [apps-discuss] Revised DMARC working group charter proposal

[Dave Crocker <[e-mail]>]

Scott,

At the risk of this going too far afield from a chartering discussion --
it might be worth moving this thread to [e-mail]:


On 4/15/2013 1:02 PM, Scott Kitterman wrote:
> On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
>> The specification has been public for considerably more than a
>> year, including a press release and a public discussion list, with
>> adoption covering roughly 60% of the world's mailboxes.  That's not
>> a small base of experience.  So there's been plenty of opportunity
>> for community review and input, including requests for changes.
>> And yet, there is so far no such list of requests.
>
> Not true.  There was a long thread, almost a year ago on the
> interaction of DMARC policy with policy aspects of other domain
> authentication technologies (SPF and DKIM/ADSP) that starts here:
>
> http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html

I apologize for being unclear.  I didn't mean that no individuals had
any requests.  I meant that there has been no demonstration of community
support -- a rough consensus kind of support -- for changes.

To my own reading, the thread you cite nicely demonstrates this:
community interest, community discussion, but no community support for 
change.  If you feel otherwise, please document it.


> While some of the issues addressed in that thread have been addressed
> (the most critical one that DMARC policy of none should not alter
> processing for SPF or DKIM/ADSP in particular), I don't think the
> issue is fully resolved.

I don't see that thread as having created items to be resolved.  Again,
feel free to document otherwise.

And given considerably more of one year for that public discussion, we
haven't identified any items that might show community support for
modifying the base specification.


> Here's the current, relevant snippet from the draft submitted to the
> IETF:
>
>> DMARC-compliant Mail Receivers SHOULD disregard any mail directive
>> discovered as part of an authentication mechanism (e.g., ADSP,
>> SPF) where a DMARC policy is also discovered that specifies a
>> policy other than "none". {R7} To enable Domain Owners to receive
>> DMARC feedback without impacting existing mail processing,
>> discovered policies of "p=none" SHOULD NOT modify existing mail
>> disposition processing. Note that some Mail Receivers may reject
>> email based upon SPF policy mechanisms before email enters
>> DMARC-specific processing.
>
> I think the initial SHOULD represents a layering violation that is
> technically inappropriate from a design perspective, will
> substantially complicate implementation, and is not needed.  Details
> to follow.

FWIW, with respect to policy mechanisms, I think this is less a matter 
of "layering" than of "replacement". DMARC is asserting authority over 
the topic of policy, to the extent is has /overlap/ (rather than 
layering) with SPF or ADSP.


>
>>> Things that were written
>>>
>>> by people who already "know" what the spec is supposed to mean
>>> are often less clear to those outside the group. Until a broader
>>> group actually reviews it, there's no way to know.
>>
>> You are correct, of course.  However the range of implementers now
>> goes considerably beyond the original group, and yet there is so
>> far no concrete list of interesting changes being requested.
>
> The current implementers don't need the IETF spec.  The RFC should be
> oriented towards future implementers

Perhaps you missed the part about there now being a number of
implementers who were not part of the writing team?  Again, one would
have expected significant critical feedback from them, about problems
with the writing, over the last 1+ year.  (But then, the latest draft
does contain revisions...)

In any event, with an area director strongly against a "just improve 
the writing" work item, and no list of changes to be made to the base, 
there doesn't seem to be much to discuss about it.


> Absent a working group to actually do some independent review,
> there's no way of knowing what would come up.

You seem to think that it's ok to start a working group when there is no 
known work other than "review the document and figure out what might 
need doing".  By contrast, my long-standing model of a working group 
charter is that there is a clear set of problems to solve and/or 
enhancements to add and that this is clear /before/ chartering.


>> Well, that's what we originally submitted for chartering, but at
>> least one AD didn't like it.
>
> Right, but the direction that the AD didn't like it was that the
> previous proposal constrained the working group too much.

He didn't seem to want any meaningful constraint.  While he, you, or 
whoever might feel that's fine, the folks currently holding the spec 
need more assurance of stability for the specification than that, given 
how recent the investment in it has been.


>  It seemed to me that there were
> a number of reasonable suggestions, including coming from the AD in
> question, that did a nice job of balancing the concerns of existing
> implementers without handcuffing the proposed working group.

That doesn't match my own reading of the thread(s).


>>> The one thing I think does need to be changed is the policy
>>> override approach.  Changing SPF policy based on DMARC is a
>>> layering violation at the very least.
...
> See the text quoted above for the specific reference.

You mean:
 >    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
...
 >    mechanisms before email enters DMARC-specific processing.
?

Where is there a demonstration of community support for changing this?


> In order to implement DMARC it's necessary for the component of a
> mail system that does SPF processing to have access to the 5322.From
> extracted from the body of the message (because of the SHOULD to skip
> SPF related policy decisions for domains that have a DMARC policy !=
> none and 5322.From provides the domain needed to determine if a DMARC
> policy is relevant for the message).
>
> Requiring data from the message body to do operations on the envelope
> is not a good idea.

Strictly speaking, it's not doing an operation /on/ the envelope, but in 
any event, the linkage to SPF's use of envelope information and DMARC's 
use of rfc5322.From information is rather basic to DMARC.

 From what I can tell, the change that you are concerned with, is 
DMARC's overriding SPF's /disposition/ mechanism, rather than its 
authentication mechanism.

In any event who supports the change besides you?  You've voiced it for 
awhile, so there ought to be some indication of support by now.


> The requirement to have access to the body of the message to do SPF
> checking in a DMARC environment is an architectural mess.

I guess I'm not seeing it as doing SPF checking.


>>> Not only is the current design wrong, it's nor needed to solve
>>> the problem DMARC was meant to solve.
>>
>> Sounds like a protocol change.  That's rather more than merely
>> improving the text.
>
> Yes, but not one that would require implementations to be changed to

...
>> The idea that one can change a design, without having to change
>> code, is new to me.  Please explain.
>
> If you change a SHOULD requirement to a MAY requirement then nothing
> forces existing implementations to change.

You mean beyond reducing the likelihood that it will get implemented; 
are you asserting that this won't affect interoperability?

But again, this is frankly moot, absent a community desire to change the 
base specification.


>>> Fundamentally, rubber stamping the work of a private design team
>>> is not the IETF way.
>>
>> What part of the work in the latest draft charter would produce
>> rubber stamping?
>>
>> But since you are being pedagogical about how the IETF does
>> things, please note that working group charters are supposed to
>> specify the nature of the work to be done.  Working groups that
>> start without a sense of what problem they are trying to solve to
>> tend to have poor outcomes.  If you can specify the nature of the
>> technical, work to be done, sufficiently to garner support for it,
>> then it's certainly worth considering.
>
> I'm aware of one technical issue that I believe to be significant
> that needs to be addressed and wasn't addressed by the private design
> group.  Unless it's in scope for a working group to review the input
> of that work to the IETF, there is not likely to be the same level of
> review.

Scott, yes it's clear that you believe the issue is significant.  What's 
missing is an indication that the rest of the community wants a change.



> Additionally, I think it is very odd to submit the base spec as an
> independent submission and then form a working group to extend it.

Not "typical", no.  So?


> As I understand it, part of a working group effort is to get
> consensus around technical efforts. I'm not sure how you get
> consensus to extend something for which there is no IETF consensus.

The question will be consensus around the extensions.  Isn't modularity 
nice?


> I might even think that perhaps that the bit in RFC 4846 about the
> IESG review where it mentioned independent submissions shouldn't be
> an end run around the working group process might be relevant.

OK.  Please point to an existing IETF effort that this might be 
considered an end-run around.  That's what that reference was/is 
intended to mean.  And who else shares this view?


>  It
> also seems to me that if the DMARC base spec seeks to modify
> processing for IETF RFCs,

It doesn't.


> I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and
> there was not also a parallel proposal for an IETF working group to
> extend DMARC, then independent submission would not be inappropriate,

So, you think that ARP was inappropriate to have as an IETF effort, 
given that essentially all of the media specifications over which it 
operates -- that is, which it "extends" -- are outside of the IETF?


d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net