We need a DKIM Policy Working Group

On 4/30/2014 11:54 AM, Pete Resnick wrote:

> If there are others who have a handle on what I'm thinking about and
> want to work on this, I'm happy to spin up a WG to work this out.
> There's no way I'm going to be able to hold the pen on this, but I
> think I hear sufficient motivation to get this done.

If you are talking about a resigner kludge that could bypass policy, 
then I am against that.  Any solution must be permission based. I 
believe that may have been your first design assumption.

I suggest spinning up a DKIM POLICY working group to begin updating:

      RFC5016 Requirements for a DKIM Signing Practices Protocol
      http://tools.ietf.org/html/rfc5016

We need to revisit and reconfirm what are the possible policies. 
What predictably started this mess was the last minute inclusion of 
section 5.3, item 10:

    5.3.  Practice and Expectation Requirements

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

That can not be anymore. Policy must be honored if this is to work, 
but the current 'method' of choice (DMARC) needs to be fixed.  If 
DMARC is going to be selected as a DKIM policy protocol, then to help 
accelerate and lower the barrier to wide adoption, then it should 
split into two:

    DMARC-REPORTING
    DMARC-POLICY

As as right now, correct me if I am wrong, I don't think reporting is 
even an option.

Thanks

-- 
HLS


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822