On Jul 25, 2007, at 7:54 AM, Arvel Hathcock wrote:
Hi all!
I believe that the algorithm specified in the latest SSP draft
(section 4.4) is the best compromise possible and that it will
cover the largest percentage of use cases. However, I agree it's
not perfect. Algorithm steps #4 and #5 are the problem as there is
no definitive list of TLDs available and yet these steps call for
the use of such. As an implementor I'm worried about how I can
comply with this part of the algorithm. These steps suggest the
use of a locally maintained or implementation specific TLD list.
But such lists would necessarily differ from one deployment or
implementation to another leading to inconsistent application of
SSP in the wild. This worries me greatly.
I'd like us to at least consider the possibility of removing the
steps associated with querying the immediate parent of the domain
in question (steps #4 and #5). Admittedly, this causes more
administrative hassles for certain classes of senders but no
solution to this question will be perfect in all cases.
I keep coming back to this: some of the brightest people I've ever
meet are members of this WG yet we are still grappling with this
issue. I think this points to the fact that maybe we can't solve
this one and that we should accept that and move forward with an
even simpler algorithm (by removing these two steps).
Anyway, I bow to the collective wisdom here of course but I'm
hoping we can at least discuss this some.
No organization is able to impose changes to SMTP without the general
consent of those creating and using the protocol. Nevertheless, to
deal with an emergence of IPv6, cryptographic assurances offered by
DKIM should prove helpful provided:
1) Common use of multiple signatures is avoided.
2) Per user signatures is avoided.
3) DKIM has an explicit single transaction means to associate SMTP
clients with signing domains.
4) DKIM has an explicit single transaction means to associate
originating email-address domains with signing domains.
(A common mechanism can deal with #3 and #4 and also deal with
multiple originating domains.)
5) Email acceptance is predicated upon the originating email-address
domain publishing an MX record or A record.
At this point in time, it should be rather rare for incoming SMTP
servers to depended upon a AAAA record for locating their servers.
The DKIM WG should push to have A or AAAA record discovery
deprecated. Deprecating address record discovery techniques will
eventually simplify where policy needs to be published. At some
point in the future, not publishing an MX record for the originating
domain might cause a message to be rejected. Either publishing
policy at every A or AAAA record is required, or domain transversal
(even limited transversal) would be otherwise required. Even limited
domain transversal should be avoided.
Points #3 and #4 can be fulfilled by placing a hash label below the
_ssp._domainkey record of the domain being associated.
See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt
A:
Query for either MX or A or perhaps ANY record at the originating
domain in question.
B:
When no MX or A is discovered, the message is suspect.
C:
When signed by a third-party domain, query for a
<hash>._ssp._domainkey at the originating domain.
D:
When the hashed SSP record is not found, the signing domain is not
authorized.
E:
When not authorized or not signed, query for the _ssp._domainkey record.
F:
When no (non-hashed) SSP record is found, there is no policy for the
domain.
G:
When there is a policy for the domain, and it is strict but the
message is not signed by either an authorized or first-party domain,
the message is suspect.
The use of explicit authorization is vital:
a) to handle possible replay abuse
b) to handle possible compromised keys
c) to avoid administrative complexities
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html