From: Dave Crocker
Sent: Sunday, September 19, 2004 12:21 AM
On Sat, 18 Sep 2004 05:30:23 -0500, Seth Goodman wrote:
Putting in a message body hash completely stops replay
with very little extra overhead at either end and makes
tracking the state of individual messages unnecessary.
Once you include a hash of the message body, then validation
requires going beyond the envelope, to look at the message
body.
It is a two-step validation process. First the recipient validates the
return-path itself before data. If this validation fails, as in the case of
domain forgery, the message can be rejected at this point. Only if the
sender validates the return-path does the recipient need to go into data.
The only reason for the recipient to match the message body hash with that
in the validated return-path is to detect a replay of a valid return-path
with a new message.
Hence it is not at all clear that you need to actually put the
message hash into the RFC2821.MailFrom BATV encoding. You might
want some linkage between the two, but that's not the same as
"including" the hash.
So far, we have only come up with two general ways to link the return-path
to the message body in a lightweight and forgery-resistant manner to detect
replay:
1) put a hash of the message body into the return-path and protect it with
an HMAC;
2) protect only the return-path with an HMAC; put a hash that covers the
message body _and_ the return-path into a header and protect it with a
second HMAC;
The second alternative has two signatures to validate. The first is to
detect domain forgeries and null-sender forgeries before data. The second
is to detect replay after data. This would require two validations, so the
first alternative appears more attractive, except for the extra length taken
out of the local-part. Of course, the signature in the header can be a PK
signature, but then the validation is much more expensive for the recipient
and the sender has to implement a key distribution scheme. Can you think of
other ways to link the return-path and message body in a lightweight manner
that an attacker cannot forge?
In any event, these sorts of extended discussions about extended
utility are fine to have, but it is potentially a rich space to
explore. One needs to remember that, to date, no messaging-based
(or, for that matter, originator-based) public key signing scheme
has gained Internet-scale deployment and use.
I am aware of that reality. It may be a fine point, but this is not a
public key signature. It is a one-way keyed hash signature that can only be
validated by the originator. But your point is well-taken. A large part of
our motivation lies in the fact that it seems likely that SPF will come to
fruition. In its present form, it cannot validate originating addresses in
the presence of forwarding and it requires changes to existing mail practice
to even deliver forwarded mail. These are major problems caused by their
choice of hop-by-hop validation, yet SPF is still moving rapidly towards
adoption.
A signed return-path protocol for validation of forwards will fix both of
these problems inherent in SPF. It will not fix the other problems of SPF,
such as excessive recursive lookups in DNS and the ability to designate
hosts that don't belong to you, but it would be a major victory to not have
to change current forwarding practices that would break non-compliant
systems. Having realized that sender validation of signed return-paths can
provide lightweight authentication of forwards, it became obvious that this
would work for direct deliveries as well. There would be no need for SPF
records or any other special information in DNS for that matter.
The likely deployment of SPF shortens the time window for experimentation if
something like this is going to be used with SPF. Once a signed return-path
validation protocol is in place as part of SPF, it is our hope that people
will realize that the SPF part really doesn't add much value and the SES
protocol provides originator authentication with less effort and less
breakage than SPF. It is a compromise between designated sender and public
key schemes. One might consider it a designated validator scheme. The
sender applies a signature and then designates a host to validate the
signatures, which happens to always be the domain MX.
So we would be wise to take that dependency out of the critical
path to the underlying MailFrom signing mechanisms. And, indeed,
that is what the current BATV spec has done, while leaving things
open for infinite experimentation with those possible enhancements.
While that is wise in terms of getting a general BATV spec on the standards
track, we are faced with a fairly narrow time window if we wish to see
something other than SRS or SUBMITTER and changes to 2822 Resent-* header
usage deployed with SPF. The people who are currently working on SES are
very interesting in finishing a protocol and writing a spec within that time
window. Most of us feel that SRS, SUBMITTER and the changes to 2822
forwarding practices would be very bad for the internet mail system. Yet
the SPF crowd does not seem concerned, nor does MARID. We have to offer a
real alternative, including a proven implementation, if we are to have a
chance at preventing this. Since one of the people in our group is the
primary author and maintainer of one of the two C SPF libraries, we are in
an excellent position to implement, test and validate something that can
achieve fairly wide distribution in a short time.
I hope this better explains our motivations. I would welcome your advice.
--
Seth Goodman