These comments on draft-delany-domainkeys-base-00.txt are mostly in
regards to architecture. ASRG and MARID are being copied as courtesy since
the proposal and this review touches on portions relevant to their work.
In general, I think that DK is a good start to a technology that I myself
have advocated ([1]) -- that signing mail from a domain instead of a user
is good enough to combat most forgeries, and that domain-wide signatures
are easy enough to implement that this approach can be successful. I also
think DK makes several mistakes in pursuit of the core objective. It's
certainly worth continued development effort, but I don't think it's worth
implementing in its current form.
1] DK suffers the same flaw as S/MIME and PGP, in that "unsigned" mail is
treated as normal, while "signed" is specially flagged. Until mailers bark
when unsigned mail arrives, then the default world view will be that
unsigned mail is the norm. The whole idea of doing domain-wide sigs is
that its easier to sign everything; using that model when its still
treated as exception doesn't make sense. Furthermore, the architecture of
storing sigs where they can be easily fetched doesn't seem to matter a
whole lot if the default is unsigned as normal.
Implementations of DK should be required to validate all incoming mail
against public signature data and flag the exceptions accordingly. If DK
is going to only verify presented signatures, then I suggest that it
doesn't really offer anything over S/MIME or PGP except for administrative
convenience (at the cost of significantly weaker sigs), and if that's the
goal then it belongs in some forum other than ASRG and/or MARID.
2] The best thing about current sig/cert models is that they carry along
mobile caches of verification data which can be validated against local
stores, which imposes the least per-process blocking. DK adopts part of
this model by tagging the headers, but inverts the critical part of the
model by pushing the cache to an unreliable external service and by
embracing the notion that everybody will self-sign everything. This is
problematic on multiple levels. For one thing, the cache has been moved
from inexpensive large disks to expensive small RAM ("but DNS is free!" no
it's not, it's somebody else's problem and still a problem). This model
also requires constant fetching of signature data, which imposes
synchronous blocking onto high-volume transactions -- you will need more
machinery to perform the same number of transfers even if you don't
validate the signatures. DK needs to facilitate the use of explicit
caching, meaning that DK needs to model around the notion of "authorized
signers" -- admins for a server need to say "I'll validate domains against
these trusted signatures, and treat the rest of them as suspect". Note
that the scope of authorized signers should be federated to the site-admin
and not defined in the DK specifications.
3] DK should be made to work with hosts in EHLO if possible. This can be
achieved if the policy statements are broadened to include hosts.
4] DK must be made to work with the envelope sender. This can be achieved
by pushing the signature along with the envelope, by way of a MAIL FROM
extension set. For example, provide something like timestamp and signature
parameters, with the signature hashing the sender address and the
timestamp as a pair (so as to prevent replay attacks), and with the
timestamp window set to ~three days so as to survive queue problems. This
kind of model (or a variation for the default-fetch model) would allow
mail to be recognized at the transfer level, would allow separation
between mailing-list exploders (MAIL-FROM) versus message authors (From:)
and so forth. I'm aware that using command parameters requires upgraded
MTAs but since DK is supposed to be MTA-level signature/verification then
we're talking about MTA upgrades already anyway. Regardless of costing,
the lack of such an ability is a major weakness of DK.
5] The weakness of the proposed key sizes is an artifact of trying to
shuffle responsibility for the cache to an external service. If you'd
accept your responsibility and design for it (as reccomended in point 2]
above) you wouldn't have these secondary and tertiary effects.
6] Concerns about the size of policy statements are similarly linked to
flawed thinking about pushing the cache to an external service that is
less capable. If you'd put the policy statements in your own service,
you'd not run into these limitations.
.] Other issues with the current design are transient and dependant on
architecture being advocated. I'll ignore them for now.
In summary, these are my recommendations:
1) Recognize that you need your own cache of authorized signatures.
2) Require validation of all domains and flag the failures
3) Provide signatures with MAIL-FROM, and with HELO if possible
That's what will be needed to do domain-wide signatures effectively, imo.
([1] http://www.imc.org/ietf-822/mail-archive/msg02133.html)
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/