Subject: [ietf-dkim] Work group future

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Mar 2011 09:34:49 -0400

As you'll see from the minutes (available at
https://datatracker.ietf.org/meeting/80/materials.html ), consensus in
the room and among remote participants at the IETF 80 DKIM session was
to close the working group after the 4871bis and mailng-lists
documents have been finished.  From the minutes:

--------------------------
4. Discussion of the future of the working group

Two charter items not yet done:
   3. Collect data on the deployment, interoperability, and
      effectiveness of the Author Domain Signing Practices protocol
      (RFC 5617), and determine if/when it's ready to advance on the
      standards track. Update it at Proposed Standard, advance it to
      Draft Standard, deprecate it, or determine another disposition,
      as appropriate.
   4. Taking into account the data collected in (2) and (3), update
      the overview and deployment/operations documents. These are
      considered living documents, and should be updated periodically,
      as we have more real-world experience.

- Is there energy and desire to do this?
- Should we recharter instead for different work?
- Should we close the working group?

Consensus in room and jabber is to close.  Will confirm on the mailing list.
Tony noted that there are changes to deployment/overview docs because of
removal of "g=", along with other minor changes.  We can handle those before
the WG closes, or Stephen (as AD) will sponsor that as an individual submission.
--------------------------

We need to hear (or read) any objection or discussion here.  The
schedule currently is to have the documents ready for working group
last call by 10 April, which means that we should be able to get them
to the IESG by the end of April, if they are, indeed, ready.  The
sense at the meeting was that after five years, the working group has
finished its productive work.

Are there objections to this?  Does anyone want to convince us that
there's interest and energy to keep it open and do more work?

Barry, as chair
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 29 Mar 2011 00:23:04 +0200

Hi,

> documents have been finished.  From the minutes:

I seem to remember that there was neither consensus for close, nor for 
continue. But I was a remote participant, so I may have it wrong.
I wonder whether there should be a followup on the figures, presented by 
Murray in the implementation report. Excellent work (thanks Murray), but 
are we satisfied with the outcome? Is 93% successful verification OK? Is 
it good, is it good enough, is it bad? What if SMTP had been designed in 
such a way, that in 93% of all cases messages were delivered with 
contents unchanged, but in 7% of all cases message content was lost or 
malformed? Would it have been a success?

What are these 7% DKIM signature verification failures, are these:

    * spammers?
    * MTA's violating the rules?
    * MTA's fixing stuff, that did not comply with the standards?
    * other?

Furthermore, I'm not sure whether the DKIM WG has concluded on thinking 
about the value of DKIM, what it can be used for. Is it's purpose 
limited to providing input to a reputation engine? Is that it? Or is 
there more than that?

Anyway, these things will not fit into the current charter...

/rolf

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2011 02:11:12 -0000

>Furthermore, I'm not sure whether the DKIM WG has concluded on
>thinking about the value of DKIM, what it can be used for. Is it's
>purpose limited to providing input to a reputation engine? Is that
>it? Or is there more than that?

Those are all interesting questions, but I don't see what they have to
do with standards development.  If at some point in the future we
figure out something where there would be a benefit if everyone did it
the same way, we can charter a son-of-DKIM group to work on it.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Mar 2011 20:12:12 -0700

Hi Rolf,

I think the simple answer is that there wasn't anything close to consensus in the room or on the Jabber to recharter to cover the questions you posed.  We didn't even have enough consensus to complete the one or two chartered items that haven't been finished.

And because of the nature of the way cryptography works, it's hard to tell what the 7% of failures are; crypto either passes or it doesn't, without telling you what broke or why.  We have some hints from the use of "z=" to compare to messages that fail to verify, but that only describes a subset of failures.  We can't conclude that the 7% are spammers because lots of signatures on spam verify just fine.  I think the answer is a mix of things you listed as well as some others you didn't.

Reputation is an application that takes DKIM as input, but is not itself part of the DKIM protocol.  Applications that consume DKIM in general have a scope outside of what DKIM can and should define.

And in general, I think this group has gone as far as it can go.  It's time for some other group, or context, to take over.  Perhaps "where do we go from here" is a question best tackled by something like the IRTF.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
Sent: Monday, March 28, 2011 3:23 PM
To: Barry Leiba
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Work group future

Hi,

      as appropriate.

I seem to remember that there was neither consensus for close, nor for continue. But I was a remote participant, so I may have it wrong.
I wonder whether there should be a followup on the figures, presented by Murray in the implementation report. Excellent work (thanks Murray), but are we satisfied with the outcome? Is 93% successful verification OK? Is it good, is it good enough, is it bad? What if SMTP had been designed in such a way, that in 93% of all cases messages were delivered with contents unchanged, but in 7% of all cases message content was lost or malformed? Would it have been a success?

 *   spammers?

Furthermore, I'm not sure whether the DKIM WG has concluded on thinking about the value of DKIM, what it can be used for. Is it's purpose limited to providing input to a reputation engine? Is that it? Or is there more than that?

/rolf

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 Mar 2011 05:15:28 -0400

Not for these two items. Barry, the issue is never about convincing 
POLICY advocates.  This "collect data" was perceived as yet another 
way to further put off completing a chartered work product.   If we 
had a true champion as the editor of ADSP, no question, it would of 
been a lively active working document and WG discussion with sincere 
updated proposal design changes because of all the high interest and 
input provided to try to make POLICY work.  POLICY was not provided 
"an equal opportunity" chance to be a) worked on, b) by a highly 
motivated believer of his work, and c) was there simply no interest by 
the editor to do anything about it to move it forward short of just 
saying it broken, by design, therefore Don't use it, 3rd party signers 
can ignore it and tried to get it removed from the charter.

It never had a chance.

We know what POLICY can offer immediate domain security. We spent many 
man-hours on it with two document products, RFC for SSP Requirements 
and RFC for Threat Analysis which were essentially ignored.  I'm sure 
any SMTP vendors in the mail business really don't need additional 
proof of concept to see a how new method effectively "legalizing" a 
new higher bar expectation for mail transactions which can help 
provide a new "legal" dissemination for  legacy operations to a very 
high zero false positive degree - with no questions asked.

So what is the real question we wish answered with "Collect Data?"

Who uses ADSP?

Thats easy, systems who support it and all existing APIs support it.

The problem is the ADSP editor has promoted the idea ADSP is broken 
and promotes the idea that 3rd party signers (like mailing list) do 
not need to support it.  So within the WG, there will be little 
incentive to support an idea not even the author supports.

I'm pretty confident having a true champion behind POLICY and we will 
we see a different positive situation occur for POLICY. I believe if 
that was to happen, the collect data would  flow like a flood as DKIM 
systems are encouraged not discouraged from supporting it.

> - Should we recharter instead for different work?

If we can get a renewed focus for DKIM POLICY with a different editor. 
Yes.

> - Should we close the working group?

I don't see any further useful outcome with a status quo. So yes, if 
we can not get a new set of supporting engineering eyes for POLICY.

> there's interest and energy to keep it open and do more work?

Barry, I'm sure you know has always been a  high interest in a 
DKIM+POLICY layer.  Its in the charter and its diminishing focus was 
not one due to primarily to technical merits but simply put we had the 
wrong person on it. It was clear and obvious conflict of interest and 
incompatible issue which should of been addressed long ago by the 
IETF.  POLICY had no change with Levine behind.  There was never a 
desire to address all the comments provided and the fact is there was 
never any updates to fix all the clear ambiguity expressed by so many.

So lets get to the real issue. What you are really asking is about the 
future of POLICY, not the WG.

I would like to see a WG whether as a continuation of this IETF-DKIM 
list or a new IETF-DKIM-POLICY WG to finally give us a chance to 
complete a solid DKIM+POLICY security protocol for DKIM without all 
the intentional anti-policy WG disruptive interference seen over the 
years.

I personally believe that if the IETF can help give POLICY a WG chance 
to be designed right, I think you will see some real positive 
adoption, marketing and confidence for DKIM. But who knows if that is 
true or not.  We don't but you (speaking in general) can not denied 
there  has always been a strong interest for a DKIM POLICY layer - its 
even a chartered item.

But we just never really had a chance.

My concern is sincere. I still have hope DKIM can help tremendously in 
the ongoing email security fight against domain fraud.   What I don't 
want to see come to a reality is the "Cry Wolf" comments such as one I 
received recently from a customer testing and exploring our new 
DKIM+POLICY implementation:

    "The initial version for non list mail worked fine for me for a 
period of time
     and then I started regularly getting DKIM=FAIL in the smtptrace 
log so I have
     not looked at again for some months."

               - Customer comment on using our new DKIM implementation

Do we really want DKIM to get into a common situation where lacking a 
protective layer for  domain DKIM signed mail becomes ignored as 
wasted overhead and bandwidth?

I hope not.

I perfectly understand the DKIM-REPUTATION model promotes the idea 
that only VALID mail (Good Mail, white listing model) should be 
considered when its signed by a trusted source.  Everything else is 
basically "undefined" by DKIM.

Fine, I won't debate the GOOD MAIL Trusted Source model.  The job was 
well done by the WG promoters of this model.  VBR seems to be 
promising as an open protocol.

But maybe the POLICY promoters can be given a chance to address a 
layer that helps protect the unsecured abusive "undefined" block 
ignored by REPUTATION.

Thanks

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com