jas at extundo.com
Wed, 13 Oct 2004 16:47:50 +0200
I read your draft, belated. I'm sure you have discussed and solved
these issues already, but just for reference, below were my initial
thoughts on the proposal.
I am not fully convinced by section 6 and 9.2, in particular: that it
is impossible to abuse the MAC key management scheme. If a spammer
can somehow fool you into talking to them, it seem the scheme is
ruined. There may be subtle technical issues here. There may even be
non-technical concerns with the approach; i.e., merely because you
talk to someone doesn't mean you want them to talk to you.
If the idea and server implementation mature, I can probably be fooled
into implementing some basic support for this in Emacs' smtpmail.el.
Secondary mail servers
There is no discussion how primary and secondary MX's interact, if
they do at all. If they are intended to interact, I believe that may
be a serious deployment issue. My experience is that secondaries
cannot be assumed to have useful out of band communication with the
primaries. Inventing and deploying a protocol to keep some
information synchronized between MX's appear to me complicated. One
of nice properties of the mail system design is that different MX's
for a domain can be separated to a big extent, making them interact
more closely seem like an unwanted direction. To illustrate the
degree of separation between MX's: some secondaries may not even know
the complete list of which domains they are secondaries for (see
If however the MX's for a domain are not intended to interact, I guess
I do not understand how the secret key authentication is going to
work. As far as I understand, the keys are stored in a database
indexed on SMTP envelope addresses corresponding to recipient and
receiver. Consider then a client that is sending mail to user@domain
via mail1.domain and mail2.domain. Which keys are used, and how are
One idea: Instead, have the keys be shared between two MTA's, and
index the database on MTA names. MTA "A" share a key with MTA "B".
Since MTAs can be known under many names, the canonical name should be
used, i.e., the <Domain> field of the 220 initial response.
Note that policy matters, such as one disabling the use of MAC keys
per-user, is still possible with this approach, as far as I can tell.
Input to MAC computation
The draft says:
If a key is found, it is used to form a MAC on data consisting of
sender and receiver id (in that order), selected headers, and the
message body. The header lines included are From, To, Cc, Date,
Content-type and Message-id. They are followed by an empty line,
and then the message body, without transport encoding (to allow
MTA's to change the transport encoding of messages in transit).
The resulting MAC is provided to the receiver during the SMTP
What do you mean by "transport encoding"? MIME Content-Type-Encoding?
If so, that appear to require a MIME decoder in the MTA, which is
complex. Further, decoding a large e-mail may require large amounts
of storage. Not all MIME libraries are written to make one-pass MAC
Finally, the format of decoded MIME objects is not well defined, which
seem to be required for MAC computations. Only the MIME encoding is
One idea: Do the MAC on the data that is actually sent on the wire.
Security properties of the MAC
There should be a security section on the highly specialized property
required from the MAC: that it is computationally infeasible to
produce a prefix MAC value with given value. As far as I am aware,
existing MACs are not designed for this property. I suspect this
property may collapse into more well known MAC properties. It would
be neat if there was a nice reduction from this special property into
more well studied properties. I.e., "if you can break the MAC for
this property, you can break the same MAC for common MAC properties".
Btw, what kind of MAC's are you thinking of? HMAC-SHA1 may be the
simplest choice, even though I would prefer something based on a block
cipher. The choice of MAC seem critical to get "fair" computation
costs, i.e., it should be difficult to optimize the MAC much more
compared to typical implementations.
In an ideal world, MUAs don't talk to MTAs, they talk to MSAs. See
RRC 2476. There may be some consequences for how the MUA discussions
are phrased. One might even consider introducing special protocol
elements for MUA<->MSA, to specify policy matters. I'm not sure that
is a good idea, though.