Date: Wed, 28 Jan 2004 21:55:58 -0500
From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
Hallam-Baker, Phillip wrote:
Wouldn't a profile of S/MIME that stores keys in DNS achieve
essentially
the same thing?
Not quite, there is a major semantic shift taking place here,
it is the domain owner rather than the email sender being
authenticated. and actually the authentication may be for the
sole purpose of getting an accreditation.
What I meant is: isn't S/MIME with keys in DNS be the same thing as
DomainKeys?
I might send you a mail from turtlerecall.com through comcast.net
and comcast.net sees it comes from a legit user who is not sending
excessive quantities of email and sign it under their domain and
policy and get the benefit of an accreditation that VeriSign
provides.
Hmmm, that would be the same Verisgn that engaged in the moral equivalent
of spamming (wildcard DNS entries leading to unsolicited marketing) last
year? I suppose that could be called a benefit to the extent that it
could be used for filtering -- but there may be some disagreement as to
whether the involvement of Verisgn indicates the presence or absence of
spam. In any event, this isn't a filtering discussion...
Nor, for that matter, is this a C/R discussion, hence the change in
Subject.
Otherwise you need an accreditation for every single domain, not
a cheap solution.
If DNS is to be used, and signing is to be used to validate the source
of a message as being that domain, then third party accreditation is
not necessary. One could simply use a public key cryptography scheme
such as DNSSEC KEY RRs.
Why do we need accreditation? The whole point of Domain Keys and similar
solutions, is to tie the email to the original domain, not a specific
accreditation authority. The DNS packet size restricts large
certificates from being used with any DNS/PKI approach, and would
require external reputation and accredition systems anyway.
There are other issues. I believe DNSSEC mentions some issues involving
sharing a private key for use over a domain.
If validation is to be used for individual senders, identified by email
address, DNS probably isn't the right place for the keys for other
reasons. There has been some limited discussion about this on the
ietf-822 mailing list; some issues are mentioned in the message archived
at http://www.imc.org/ietf-822/mail-archive/msg03987.html
and a brief outline of how keys might be handled via an SMTP extension is
in http://www.imc.org/ietf-822/mail-archive/msg03941.html
With S/MIME we can have the outgoing MTA or MUA sign the message, or
even both: MUA signs with sender key, and MTA resigns the signed message
body with the domain key. This way you can have the same effect as
Domain Keys seems to provide, plus a possibility for sender
authetication as well.
And the possibility of encryption. There is even the possibility of
step-by-step verification (each successive MTA handling a message
signs what it receives using S/MIME), though an end-to-end verification
is likely to be more practical. And if MTAs handle the keys associated
with a sender's email address, the signing and verification can be
performed at the MTA level, transparent to the MUA and user.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg