No, you didn't have the last word :-). Some messages just require more thought
than others.
At 11:13 AM 10/6/2004 -0400, James M Galvin wrote:
The primary issue that I am raising is the conflict betweeen the phrases
"transit-time use" and "authenticate the author or sender".
If the goal is to authenticate the original author or sender, normally
called the originator of the message, then I remain completely opposed
to this working group. To me that goal is "reinventing" secure email
(PGP, S/MIME, whatever) and, speaking personally of course, I have not
seen any compelling reason for doing so.
On the other hand, if the goal is best represented by the phrase
"transit-time", I may be in favor of this working.
I'm not sure I'm happy with either of those phrases. When it says
"authenticate the original author or sender" it sounds like there is some sort
of hard binding between the message and a person; no anonymity is possible.
There are use cases that depend on the relative anonymity that we currently
have in the mail system, and we should preserve that behavior. I prefer the
description (even if it's not precise) that we need to authenticate the
message, and verify the authorization of the sender.
In your subsequent comments, I think you have interpreted "transit-time" as the
time between MTA hops. Transit-time could also be the entire path between when
the sender pressed "send" or equivalent, and when it was displayed to the
recipient. This means that it could be an end-to-end mechanism (which is what
I think we need) and not just hop-by-hop.
Alice is an MTA with a message M that Alice controls. How Alice
came to control M is confidential to Alice. Perhaps an MUA
submitted M to Alice. Perhaps another MTA relayed M to Alice. In
either case, the initiating side of the connection that gave Alice
control may or may not have been authenticated. There is no way to
know without explicitly asking Alice through some out-of-band means.
Alice is willing to take responsibility for controlling M.
So, in effect, you're saying that any MTA can take responsibility for any
message. I'm concerned that, without some safeguards, this is too much of a
loophole. There are certainly some circumstances where this needs to happen
(mailing lists that modify the message, for example). By making the operators
of MTAs, and not originating domain administrators, responsible for messages,
you're separating that responsibility from the entity that is likely to be
harmed by a spoofed message. I believe it's important to give domain
administrators, and not arbitrary MTA operators, control over the authorization
of messages.
The critical phrase above is that the signature asserts the identity of
the prior hop that controlled the message. Nothing more, nothing less.
It is a "domain-based" identity. In particular, it does not
authenticate the sender or author.
So every hop that handles a message needs to support this mechanism in order
for it to work. I receive much of my personal mail through several forwarding
addresses. I am able to verify end-to-end signed messages that go through
those forwarders, today. But I would not be able to use a hop-by-hop mechanism
until each of them had implemented it. And I would need to understand the
policy of each to know how to interpret the signatures they add.
I'm not understanding your argument against an end-by-end mechanism where the
signature semantics differ from the usual PGP or S/MIME model.
Both S/MIME and PGP actually support more than one means of conveying
that information: security multiparts and something unique to itself.
Do we need another means of conveying the security information?
That's a key question. I and others think we do. We should probably break
that question down into (1) whether a MIME encapsulation must be required for
all signed messages and (2) choice of keying model (certificates, web of trust,
etc.). IMO there are enough problems with issue (1) that we don't need to go
further.
-Jim (oh-oh, too many Jims here)