[Top] [All Lists]

Re: [ietf-dkim] The problem with the DKIM design community

2013-06-23 11:03:49
Oh, I didn't know there was a requirement for one to have IMPLEMENTED 
and DEPLOYED proposed protocols before one can have any sort of 
engineering insight into problems and their resolutions?  I'm sure that 
is not what you mean.

Sure, it helps, but keep in mind DKIM itself was engineered with little 
to no DEPLOYMENT experiences by the very authors themselves for a very 
long time.  Many folks here were in the same position, including us 
(Santronics Software) only finally implemented and deployed when there 
was a sign of a payoff with an Author Domain protocol work product in 
the WG.  Nonetheless, not having deployment experiences should not mean 
we don't know what we are talking about and I surely hope that doesn't 
become the next mantra to participate in the IETF WG process.

And consider also, that many of the current problems with DKIM and the 
lack of a payoff were 100% predictable and foretold by many here, 
including myself, including Mr. Otis.  Recall the "battery required" 
talk?  While there as direct experience for me with the early Visanet 
market, this was discussed even during MARID. It was well foreseen as 
the wrong path for DKIM to use without an AUTHOR DOMAIN layer to it.  It 
was a early rejected proposal to use a Reputation (GOOD) layer. Remember 
CSV/DNA?   Its no surprise that DMARC is now following author domain 
concepts offered by SSP, DSAP and ADSP.

Remember, DKIM had SSP built-in. It was removed. IMV, that was when all 
the second guessing began with DKIM and in my view, it was clearly the 
wrong thing to do when SPF was still coming on with strong definitive 
handling (rejection) semantics which DKIM failed to establish. 
Practically everyone was looking for a strong rejection based protocol 
for mail.

Remember that DKIM's original charter stated Mailing List was to be 
looked at as an after-thought to the main consideration with policy. 
Mailing list WAS NOT the prime consideration - it was written in the 
charter as a secondary consideration.   The problem is that we had to 
now cater to the 3rd party channels.  A valid concern but one well known 
to be fraught with major issues with middle-ware design concepts.  But 
we allowed this side of the design community and market to trump all 
others higher value private transaction concerns. It was "too small" to 
consider.   That was a mistake. And remember, there were proposals, 
ideas to allow the middle ware to work, but then we had to forget about 
author domain policies to allow for a futuristic "battery requires" 3rd 
party reputation/trust resigner market to work.
DKIM Deployment's guide conflicts on this very concept - support ADSP, 
yet allow for middle ware to ignore ADSP. Nuts! Guarantee Author Domain 
Protocol killer if you can't get the middle-ware folks to support 
honoring Author Domain policies - all known long ago without or little 
deployment. I was proposing in DSAP that both can co-exist.  But no, the 
reputation folks did not want Author Domain policies to dictate over 
middle-ware signatures.  That little last minute was stipulated in the 
SSP Functional Specs RFC and it KILLED IT!!  Why bother now.

So it is what it is today; a very little to zero DKIM payoff.  Systems 
signing with some marketing value, and perhaps processing/verifying but 
there is no expectation that it has any handling value.  DKIM is 
currently a big waste of processing time. Super high waste and the 
bigger you are, the more waste you have and more you absorb as well.

Will DMARC change that?  Only if you get the small folks - the MAJORITY 
of the network, involved.  That is why SPF took off - it was the entire 
industry that jumped on board to support a REJECTION based protocol that 
was so drastically needed at the time. For DKIM, it really came a day 
late and a dollar short and when SSP was removed, well, it only made SPF 
that more stronger.

The IRONY in the DKIM story is that the same folks that didn't like SPF, 
came to realize that it needed SPF to help DKIM.  Now you have the same 
group of authors doing all three.  That could be good but they really do 
need to begin listening (and reading the mail) of the Author Domain 
advocates. So much time wasted.

To me, it may be too late.  The only way to jump start all this again is 
to come up with real strong technical sales/advertising/discussions for 
the support of real Domain Handling policies - that is when the 
WORTH/PAYOFF factor and new processing ideas will come.  In the mean 
time, it (DMARC) is just more waste with yet another TXT-based record 

   SPF EHLO/HELO optional

and now we add DMARC?


That is basically what? 5-8 TXT Lookups?  Ridiculous!

Perhaps the group of folks putting all these things together should have 
a IETF lunch meeting and start thinking about better consolidating all 
this TXT-based worthless lookup into some single cohesive author domain 
with 3rd party/mail list support solution.

Just look at the TXT vs unique/new RR type debates. Another TXT-based in 
DMARC will not well.  Too much.  We need a single author domain protocol 
consolidation that is extendible, flexible to support a wide range of 
ADMD declarations. It will support SPF, VBR and DKIM domain policy 
layered protection ideas.

I think Murry can write it and get wide support (wide to me is small to 
large, no exceptions) if done correctly.


On 6/23/2013 7:28 AM, Franck Martin wrote:

Michael, if you don't want to deploy, that's your prerogative, but don't 
claim supposed problems are blockers when you don't have any experience of 
such deployment...

On Jun 23, 2013, at 1:06 AM, Murray S. Kucherawy 
<superuser(_at_)gmail(_dot_)com<mailto:superuser(_at_)gmail(_dot_)com>> wrote:

On Sat, Jun 22, 2013 at 9:49 PM, Michael Deutschmann 
(I have deployed DKIM alone senderside, but that's just to keep in
practice in case someone invents an accessory protocol that's actually
sane.  Allowing me to declare that all mail bearing my RFC821 MAIL FROM:
without a corresponding signature is bogus while saying nothing about
that which merely bears my RFC822 From: would be a good start.)

If that's the magic you seek, I propose writing it up as an I-D and doing 
some practical interoperability experiments, and see if it takes off.

It's easy to lob "you should've done it this way" grenades without actually 
putting any energy behind it other than a critical missive here and there.


NOTE WELL: This list operates according to

NOTE WELL: This list operates according to

NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>