Subject: [ietf-dkim] Can vendor's really say they have DKIM support yet?

From: Jeff Macdonald <[email-masked]>
Date: Wed, 1 Feb 2006 11:36:44 -0500

The standard isn't finalized yet, correct? So how can we have vendors
say they have conforming implementations?

I'm talking DKIM, not DK.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Feb 2006 08:49:44 -0800

> I'm talking DKIM, not DK.

The version of DKIM that was submitted to the IETF was the result of an 
extensive, multi-vendor specification and development effort.  In effect, the 
IETF effort is for the purpose of creating version FOUR of DomainKeys.  By this 
measure, version THREE is first one called DKIM.

Please take a look at <http://mipassoc.org/dkim> for more information.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 1 Feb 2006 13:53:29 -0500

On Wed, Feb 01, 2006 at 08:49:44AM -0800, Dave Crocker wrote:
> extensive, multi-vendor specification and development effort.  In effect, 
> the IETF effort is for the purpose of creating version FOUR of DomainKeys.  
> By this measure, version THREE is first one called DKIM.
> 

Dave,
Thanks for the response. So just implementing
http://mipassoc.org/dkim/specs/draft-allman-dkim-base-00-10dc.txt
without SSP is considered a valid DKIM implementation?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 01 Feb 2006 11:18:37 -0800

or the response. So just implementing

 > without SSP is considered a valid DKIM implementation?

As I recall, people have had some debate about this exact point.

I believe, quite strongly, that implementing the core signature mechanism 
definitely qualifies as implementing DKIM.

This does not mean that SSP -- or any other bit of additional DKIM technology 
that gets developed -- is unimportant, ill-advised, or any such negative. 
(However I believe there is general agreement that the core is more stable than 
ssp, where 'stable' means that changes to the respective specs are likely to 
entail a smaller percentage of code, data, or operations changes.)

Anyhow, my own view is that it merely that the signature mechanism, itself, is 
sufficiently useful to warrant being called DKIM.

But, of course, that's merely my own view.

d/
-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 1 Feb 2006 14:57:12 -0500

----- Original Message -----
From: "Jeff Macdonald" <[email-masked]>
To: <[email-masked]>

> without SSP is considered a valid DKIM implementation?

For the list IETF record, If true, I believe quite strongly, with the
hat of a senior software engineer, find this highly irregular premature
promotion of an unsafe non-standard.

If Steve Atkins assertion is true and early adopters will be bulk
mailers and distributors,  just consider the impact that it will impose
of SMTP receivers who will undoubtedly find issues with guaranteed to
occur mix policy exploits with no SSP verification protection.  Systems
will take matters into their own hands, ignore it or use DKIM signed
mail against the bulk mailers thus reducing DKIM to yet another wasted
bandwidth contribution to the net.  Worst, advanced derivatives that
secure DKIM protocol will surely emerge.

In my opinion, any good actor member of the bulk mail community or DMA
will be risking their reputation and mail distribution operations with a
DKIM only concept.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Feb 2006 20:37:37 +0000

Dave Crocker wrote:
> I believe, quite strongly, that implementing the core signature 
> mechanism definitely qualifies as implementing DKIM.

While I don't disagree with Dave, I guess I ought to point out
the obvious, just for the record. Hopefully, there's no debate
needed.

Implementing an Internet-Draft is not implementing a standard.
For the latter, the RFC has to exist.

If you choose to write code based on an Internet-Draft you are
taking a risk that the specification changes before it becomes
a standard.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 1 Feb 2006 16:37:47 -0500

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 01, 2006 3:37 PM
Subject: Re: [ietf-dkim] Can vendor's really say they have DKIM support
yet?

> taking a risk that the specification changes before it becomes

This is only a concern for a local operation.

The problem is the impact this premature promotion of a unsafe DKIM only
methodology will have against the network and other systems.

The same is true with e-mail. Stable technology but the known issues and
neglect to address its safetyness got it where we are today.

History is repeating itself.

Since the 80s, it was well known the reverse-path was exploitable and
unsafe, but it was deemed as a low impact threat.

By 2000, when RFC 821 was updated to RFC 2821, it was still believe to
be a low impact threat in its security considerations, only this time it
was written in stone in RFC 2821:

  7. Security Considerations
  7.1 Mail Security and Spoofing

  ...

  This specification does not further address the authentication issues
  associated with SMTP other than to advocate that useful functionality
  not be disabled in the hope of providing some small margin of
  protection against an ignorant user who is trying to fake mail.

However, RFC 2821 had the hindsight to leave the reverse-path
verification concept open for implementation with a relaxed provision:

  3.3 Mail Transactions

  .............  Despite the apparent
  scope of this requirement, there are circumstances in which the
  acceptability of the reverse-path may not be determined until one or
  more forward-paths (in RCPT commands) can be examined.  In those
  cases, the server MAY reasonably accept the reverse-path (with a 250
  reply) and then report problems after the forward-paths are received
  and examined.  Normally, failures produce 550 or 553 replies.

Now we have once again a premature promotion of a proposed technology
that has known issues and obvious exploits.

What will happen is that the establish market of DKIM only systems will
finally someone realize there are major exploitation issues.  The
updated RFC called SSP or something is required.   But it will be too
late.  You will have two different markets to deal with.

Proof of concept testing is one thing. Promoting it as a stable safe
technology is simply premature in my opinion.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Feb 2006 13:47:44 -0800

> mechanism definitely qualifies as implementing DKIM.

Frankly, the IETF isn't the police so this is a pretty moot point. But 
if you're interested
in truth-in-advertising, making explicit that you abide by -base and/or 
-ssp would
at least give an interested person the tools to make a better informed 
decision.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 1 Feb 2006 14:16:18 -0800

On Feb 1, 2006, at 1:47 PM, Michael Thomas wrote:
>
> Frankly, the IETF isn't the police so this is a pretty moot point.  
> But if you're interested in truth-in-advertising, making explicit  
> that you abide by -base and/or -ssp would at least give an  
> interested person the tools to make a better informed decision.

It would seem recommending DomainKeys might be a more conservative  
choice for the moment.  Interchange issues would be less daunting  
when not including each iteration of a draft undergoing  
modification.  As it is now, some same-version variations of DKIM  
should be precluded due to security considerations.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Wed, 1 Feb 2006 23:06:19 +0000

> taking a risk that the specification changes before it becomes

It's probably not the intent, but this could be read as discouraging
such activity. On the encouragement side, it's worth stating the
obvious that implementing I-Ds is probably one of the best ways to
find problems, oversights and other glitches that are not obvious in
the abstract.

Also, from a "marketing" perspective, the question we used to get in
the early days of DK was "who else?". One expects the same with
DKIM. Pointing to players that are investing the effort and producing
product, albeit with the risk of change, strikes me as more positive
than negative.

In any event, as Mike points out, keen/aggressive vendors are going to
do this regardless of what we think or say on this rather obscure
corner of the Internet.

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Feb 2006 23:16:54 +0000

Mark Delany wrote:
> such activity. 

It was of course not the intent. Having worked on IETF specs. where
everyone lost interest and went home before an RFC issued, I find
the level of activity here very encouraging (if somewhat time
consuming;-). My note was, as I said, for the record, in case
there's someone on the list who's not familiar with the process.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 1 Feb 2006 23:40:39 -0500

From: "Mark Delany" <[email-masked]>

> product, albeit with the risk of change, strikes me as more positive

This is necessary and hopefully testing within well defined limited
sittings, aka "ALPHA" mode.

But when you begin to use it in production mode, it places an impact and
burden equal or greater as well on others that you presenting this new
information too.

One will argue, the t=y policy attribute can be used for testing:

   5.  Policy Syntax and Semantics

   t= A vertical-bar separated list of flags (plain-text; OPTIONAL,
      default is that no flags are set).  Flag values are:

      y  The entity is testing signing policy, and the verifier SHOULD
         NOT consider a message suspicious based on the record.

But as pointed out with a real world example back in November 9, 2005.

     http://mipassoc.org/pipermail/ietf-dkim/2005q4/001323.html

This is a threat and exploit when Bad Actors use t=y to get around any
irregularity of their DKIM "emulations" in messages.

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 02 Feb 2006 11:04:58 -0600

> without SSP is considered a valid DKIM implementation?

Just my opinion but I consider such implementations valid - just 
incomplete.  I have no problem with claims of "DKIM support" or "DKIM 
enabled" by such implementations (although it would be clearer if those 
implementations stated that they supported base only and not ssp).  I 
think eventually a "fully DKIM-enabled" product will have to embrace all 
the parts of DKIM though.

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 02 Feb 2006 11:10:12 -0600

> taking a risk that the specification changes before it becomes

Very true so if you do decide to do this (as I have) you must be 
diligent about it and prepared to make timely changes as necessary. 
However, the alternative (not implementing until the full spec is 
realized) also carries risk.  Many times you just don't know the full 
impact of something (or all the bugs in it) until it is deployed (and on 
a scale beyond that of a simple test lab).  Somebody has to take on the 
risk.

-- 
Arvel