ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Work group future

2011-03-28 22:18:10
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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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,

On 3/28/11 3:34 PM, Barry Leiba wrote:

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.

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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>