----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, February 01, 2006 3:37 PM
Subject: Re: [ietf-dkim] Can vendor's really say they have DKIM support
yet?
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.
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org