On Wed, 2004-12-15 at 13:08, Robert Barclay wrote:
On Mon, 2004-12-13 at 12:05, Douglas Otis wrote:
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.
This concept can be turned around. The Originator is authenticated by
the Submitter. The Submitter holds the private keys and has authorized
the sending of the message.
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.
This seems to be enforcement of a Submitter policy. A rule by the
Submitter enforces what is allowed to exist within the From header. The
Submitter then asserts their enforcement policy, and this achieves the
desired goal of constraining the From. This would seem to be a matter
of policy, where not every Submitter may assert this enforcement. You
are advocating that the Submitter be the holder of the private keys and
therefore is the entity doing the authorizations.
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).
A "self" authorization removes a fair amount of control and the ability
to capture a record of what had been signed by the domain. It also
opens up a fair amount of risk, as, when a key gets compromised, it may
have been in the hands of many individuals. Which individual has the
security problem? How do they get notified to stop using their keys?
How soon could a new key be distributed when there is a known security
problem? Unique keys for each user is the typical solution. ISPs will
be able to offer domain signature services for small businesses. It
seems submission ports are not that hard to implement, if these ISPs are
also implementing a specific domain signing MTA on behalf of these small
companies.
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.
We seem to be talking about mail policy of the Submitter again. A means
of asserting policies can afford greater reliance upon the From. This
would be an assertion made by the Submitter in their role of
authenticating the Originator.
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.
I don't think this level of signature/header gymnastics is required to
have the Submitter assert that a From field has been checked to some
level.
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.
These concerns are real, but independent of the header used to reference
signature validations. I don't think the problems of key distribution
should be underestimated as just another problem among many. Part of
the signature/key issues may be the need to assert policy. The issue of
policy is being addressed in different ways.
-Doug