JCL's objection to RMX that it gives the DNS admin too much control strikes
a chord with me. However, I do think that the DNS admin should have some
control over email from his domain: specifically, he should have control
over who sends mail purporting to be from that domain. Like JCL, I don't
think he should have control over what mail is sent in the way that RMX
would give him it (mostly because RMX would allow him to force all mail
through some particular MTAs where he could do content filtering).
So I guess we need a proposal which gives the DNS admin the right level of
control.
Here is a first rough idea.
The DNS admin provides a set of public keys as new DNS records (along the
lines of Paul Vixie's proposed Mail From MX records, so no big
implementation hassle for DNS) along with a key index for each key (just a
tag distinguishing it from all the other keys for the same domain). He
hands out corresponding private keys to people who are authorised to send
email apparently from his domain. He can choose to have only one key for
everyone, to give different keys to different groups or individuals, to give
some people more than one key, and so on.
Note that there's no trusted third party actring as a CA or anything similar
here. The domain admin creates key pairs, the public keys don't have to be
certified or signed by anyone.
Then we change the HELO command so that it takes the form
HELO SP <hostname> SP K<key index> SP <seed> SP <expiry date> SP <start
date> SP <signature> CR LF
[where <hostname> SP is optional]
(maybe it would be cleaner to use extended SMTP and put this stuff as
parameters on the MAIL FROM line)
where
<key index> indicates which of the domains key pairs is used for the
signature
<seed> is some "random" data
<expiry date> is the last time at which the signature is to be considered
valid
<start date> is the time at which the signature was formed
<signature> is the result of encrypting (RSA, using the private key for
the domain corresponding to <key index>) the contents of the helo line
following K and preceding <signature> concatenated with the adress in the
MAIL_FROM line.
A receiving MTA checks the signature. If it doesn't work, the message is a
forgery. If it does work, it's genuine or there's been a replay attack. If
SP K SP doesn't occur on the helo line, the MTA can't do the checks and we
don't know anything. If the <key index> is out of range, the message is a
forgery. If the MTA doesn't do the check, we don't know anything. If the
MTA is a relay, it should pass the part of the helo line from SP K SP to the
end on to the next MTA in its helo line, but current MTAs certainly wont so
MTAs downstream of them can't do any checks.
This doesn't identify individual senders unless the domain has handed out
individual keys. If the domain owner wants to get RMX like behaviour and
excercise dictatorial control, he gives the keys to no-one and generates the
signatures in his smart-host. If the domain owner doesn't want to play this
game, he doesn't provide any key records in DNS.
The problems I see are
replays: could be fixed by signing message body (excluding content
headers, since MTAs can add to these) and is mitigated by the timestamps
not-attributable mail: we only identify the domain which has permitted
the sender to use its name.
mail list expanders have to re-sign if they change the envelope mail_from
users will leak keys all over the place
requires change to MUA as well as MTA
The advantages:
Eliminates the "dictatorship" objection to RMX (but allows domains to be
set up as dictatorships if the domain owner wants them that way)
It doesn't require certificates and CAs
It doesn't need a key per mail user, and mail users don't get involved in
generating keys
S-MIME and PGP are technically better than this but require per-user keys
and do require certification (an unsigned PGP key on a PGP key-server is
useless for authentication, isn't it, and completely useless for tracing the
source of an email) which are things to avoid if we want any significant
deployment. They aren't any better about leaking keys (if every user has a
key, many of them will leak their keys). So looking at practicality rather
than technical goodness, I think this could be the basis of something
better.
Tom
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg