-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Douglas Otis
Sent: Monday, December 13, 2004 12:05 PM
To: Robert Barclay
Cc: 'IETF MAILSIG WG'
Subject: RE: Sender signatures are useful for...?
On Mon, 2004-12-13 at 09:12, Robert Barclay wrote:
On Thurs, 2004-12-09 at 2:19 PM Douglas Otis wrote:
On Thu, 2004-12-09 at 11:50, wayne wrote:
Michael Thomas <mike(_at_)mtcc(_dot_)com>> writes:
So it seems that a lot of people are taking it as axiomatic
that a Sender: signature provides some utility.
Personally, I see very little utility in protecting the Sender:
header, and far far less in protecting the Resent-* headers. I see
a
lot of utility in protecting the From: header, the envelope from
(2821.MAILFROM), and the HELO domain.
How does this get deployed? The From is a function of the Originator
and can be a domain independent of the Submitter domain.
I actually see this as an advantage for signatures on the From rather
than a
disadvantage. In the case where the Sender and From domains are
identical
there is obviously no problem with key distribution. In cases where
businesses have relationships which allow real authorized mail using
their
domain to be sent from outside of the administrative domain this gives
them
a clear way to express that authorization and accountability for that
use of
their domain.
Obviously, private keys could still be used in Submitters of those so
authorized. A desire to distribute authorization in this manner is not
inhibited by the use of Submitter. The number of private keys
distributed in the case of the Submitter are much fewer than to
Originators.
The primary issue is not who the keys are distributed to but whose
authorization is being expressed. The most meaningful authorization that I
can think of for a Submitter is not that they really were the Submitter but
that they are authorized to send on behalf of the Originator.
To achieve this does not mean that every Originator/RFC2822 be provided with
a key, or that they generate a key. This means that each valid Submitter
domain be issued a key authorized by the domain of the Originator.
The only case where an individual Originator would need a key is when a
domain has authorized that Originator to "self-authorize" their mail
regardless of what Submitter they may be using (one case of for this might
be small businesses who own their own domain but not actual infrastructure
and have to send through their ISPs MTA).
In these cases it will normally be the RFC2822.Sender (or more specifically
an MTA for the domain of the RFC2822.Sender) who does the signing, but the
domain they are signing for is the domain of the RFC2822.From using a key
provided by the owner of that domain.
This of course, and by intention, means that the authorization can only
extend to submission sources known to the owner of the domain contained in
the RFC2822.From.
The owner of a domain is likely only going to accept accountability
for mail sent through domains with which they have some type of
relationship. If the key verification requires a query against the
domain owner and the keys are distributed by the domain owner to all
sources they accept accountability for (which likely would include
things like third parties who mail on their behalf, the MTA's of
traveling salesmen, in addition to their own MTA's) then we would have
a pretty complete list of everyone that domain owner has taken
positive steps to indicate as an authorized Submitter for their
domain.
The private key is the means of distributing authority and has no other
relationship to the source of the message. If based upon the Submitter,
a traveling salesman will likely use a submission port or a VPN to
exchange messages, if signed by their company. This also allows the
company to track their signed communications, which is becoming a
growing legal requirement.
You have not addressed how private keys would be distributed to the
Originator as apposed to the Submitter. If so, how many more keys will
then need to be tracked, revoked and verified? How many more components
will need to change?
Again, there are already methods of distributing keys to the
Originator. Why do you think this has not gained greater use? By
limiting the signature function to the Submitter, the issue of keys
becomes much simpler to administer and deploy, and offers greater
control in its use.
What has not been successful (or at least very widely adopted) are the
existing message signing technologies. I think there are a number of reasons
for this besides key distribution among them are the effects of message
signing on recipient experience (which has been described on this list
previously), and the at least perceived lack of any benefit for doing so in
most cases (if it costs me money to implement, may pose some risk to
implement, and no one is using the data anyway why would I do it). Unless
these two concerns can be overcome organizations are unlikely to get to a
point in their discussions where they would even notice that key
distribution might be a problem.
Robert
-Doug