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

[Scott Kitterman <[e-mail]>]

On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
> Scott,
> 
> On 4/12/2013 11:00 PM, Scott Kitterman wrote:
> >> So Scott, what changes to the DMARC base spec are you seeking and
> >> why and who wants them and how do we know this?
> > 
> > In part, I don't. DMARC has been developed in private by a relatively
> > small group of people. I think it's not unreasonable to consider the
> > spec might be improved by broader review.
> 
>     It's entirely reasonable.  That's why the draft charter provides for
> such future effort: "However, if resolving any of the issues listed in
> the areas of focus below does require changes to the base specification,
> or if the specification needs to be revised to correct technical errors
> deemed essential for proper use, the group will recharter accordingly."
> 
>     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

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

>  >  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 (Ironic note: I was on the other side if this 
exact question about 4408bis in SPFbis and lost - I am now convinced that this 
view is the right one).  

Absent a working group to actually do some independent review, there's no way 
of knowing what would come up.  The currently proposed charter, by design, 
minimizes the incentive to actually do so.  The only IETF review of the base 
spec would be a, by design, very limited scope review by the IESG.

> > That's not a matter of changing the protocol, but improving the text.
> 
>     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.  Removing the work entirely 
from the working group seems like doing the opposite of addressing the 
concern.  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.  I think the current draft charter is an over-reaction in the wrong 
directions.

> > 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.
> 
>     Sorry, but I'm missing the reference.  Please point to the section
> of text you don't like and describe the kind of change you are seeking.
> 
> (FWIW, on reflection, I'm not a fan of the term policy override, since
> it implies that the recipient has somehow been bound to conformance to
> the sender's policies...)

See the text quoted above for the specific reference.  

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.

> > While reading the envelope (HELO/5321.Mail From) I
> > have to change processing based information in the body (5322.From).
> > Many SPF implementations don't have access to the body making it
> > difficult to implement correctly.
> 
>     If they are doing DMARC, they do have access.

Eventually, but not necessarily when the SPF processing is done.

I have currently deployed DMARC verification for testing (I'm adding the 
relevant authentication results header fields, but not enforcing reject 
policies).  I'll use my current setup as a specific example of why following 
"SHOULD disregard any mail directive discovered as part of an authentication 
mechanism (e.g., ADSP, SPF)" adds substantial complexity to implementation and 
deployment due to the layering violation inherent in that requirement.

For this deployment, the MTA is Postfix, the SPF verifier is pypolicyd-spf, the 
DKIM verifier is opendkim, and the DMARC verifier is opendmarc.

Postfix has an "Access Policy Delegation" interface 
(http://www.postfix.org/SMTPD_POLICY_README.html) that is used by pypolicyd-spf 
to do SPF verification during the SMTP session.  SPF 5321.Mail From and HELO 
results are determined and, if the mail is not rejected/deferred, an 
appropriate Received-SPF or Authentication-Results header field is added.  This 
is done after mail from or rcpt to.

After the body of the message is received (after data), it is passed via the 
milter interface to opendkim for DKIM verification (which adds an 
Authentication-Results header field for DKIM) and then to opendmarc which also 
adds an appropriate Authentication-Results header field (since I'm not 
enforcing DMARC policy yet, it always just adds the field).

SPF checking via the "Access Policy Delegation" interface is the standard 
approach for Postfix deployments (in fact, the interface was specifically added 
to support SPF checking, although it is used for many other things as well).  
As is appropriate for an MTA, the policy interface operates on the envelope of 
the message and does not provide access to the body of the message, which 
typically has not been transmitted when it is invoked.

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

> > 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 fix, which 
I think is the important point.  I believe that SHOULD/MAY in "SHOULD 
disregard any mail directive discovered as part of an authentication mechanism 
(e.g., ADSP, SPF)" is probably sufficient, but since they can already do that, I 
don't know what the point of even having it in the spec is.

> > Similarly, due to this override, a DMARC policy of none can't be used
> > just to collect data as it will change mail processing as well.
> 
>     I don't understand.

This particular aspect of the issue has been corrected in the current draft, 
sorry for dragging it in.

> > The current design is wrong. The specific issues I'm concerned with
> > now can be resolved without forcing existing implementers to change
> > anything, so no investment is at risk.
> 
>     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.  The can, but they don't have to.

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

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

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.  It also seems to me that if the 
DMARC base spec seeks to modify processing for IETF RFCs, it's pretty much 
inherently a conflict of the type that IESG review of independent submissions 
is supposed to identify.

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, but I'd still prefer to see 
DMARC standardized through the IETF.  I think that there will be a better 
product as a result (and I also think it's not at all difficult to craft charter 
language that will adequately address the equities of early adopters).

Scott K