On Tue, 2004-12-21 at 11:59, william(at)elan.net wrote:
On Tue, 21 Dec 2004, Douglas Otis wrote:
On Tue, 2004-12-21 at 01:36, David Woodhouse wrote:
On Mon, 2004-12-20 at 17:13 -0800, Douglas Otis wrote:
I suggested another method would be to flip how Resent-Sender and Sender
are handled in the case of user forwarding.
If we want to change how things are handled in the case of user
forwarding, surely we might as well have adopted SPF and SenderID?
Signatures protect the Submitter entity.
I do not agree. Submitter is more closely tied to the network responsible
for last hop and can thus be protected by IP-based per-hop system. This
is not to say that it can not be protected by cryptography - it certainly
can and its safer way to do it, but IP-based system will work for submitter.
But ip-based schemes will not work for real email sender, which is the
start of email path - that is the core of the failure for SID proposal.
The Submitter would be responsibility for preparing the message for the
mail transfer service. I would not consider that a last-hop function.
Dave Crocker has a role breakdown at:
http://brandenburg.com/specifications/draft-crocker-mail-arch-01.html
A separate set of definitions can be found at:
http://www.ietf.org/rfc/rfc3888.txt
Submitter (Sender) would be the entity interacting with the Mail
Submission Agent and these roles could be seen as somewhat merged in the
case of centralized signatures. I am sure Dave will correct me on this.
Unlike path registration, a signature is a safe method for assessing an
accountable entity (domain) granting access.
Yes. And addition of new signatures will allow to do it for each hop, but
the important part is being able to recognize where email message
originated and protect original sender.
This statement is difficult to understand. I see the role of Submitter
(Sender) (combining with a private function within the MSA) providing
signed messages. The Originator is protected only by policies in place
within the Submitter domain. How the Originator/Submitter is
authenticated and the message constrained would be determined by
policies within the Submitter domain. Signature protection for the
Submitter extends these policies protections to the recipient.
Not all domains will have equally stringent policies and thereby offer
more or less protections for the Originator.
Just as CSV allows name identification beyond the IP address,
CSV and SPF protect data used during SMTP Session. This is the data that
can be quickly seen and verified even before the email is transmitted
but at the same time session data is not carried over to the end point
beyond some trace information. I'll note also that session verification
was correctly called "LMAP" - lightweight mail authentication, it requires
less cpu work and is easier to deploy but not quite as good as cryptography.
But I personally believe that its important to protect both the session and
data and that they are different layers and that protection for both should
not be intermixed. Each one should be able to work on its own but if they
are both protected that is even better - two borders is better then one
but each border should not be a half-line or we have no border at all!
There is a substantial difference between authorization and
authentication, but will agree there will remain a need to use
reputation protection within the initial session. This role is handled
by CSV and is the subject of a different work group.
the signature allows name identification beyond the last hop.
Exactly.
Accurate accountability is required to establish reputation, and that is
not possible using path registration that requires intervening security
and consistent checking, neither of which are verifiable.
Reputation should rely on the strong identity and only cryptography can
provide that.
I really think we need to design something which actually works in the
majority of the real world, without requiring change from people who
aren't participating.
Agreed.
Agreed as well.
Requiring a small amount of change from people who _are_ participating
(like "thou shalt add Return-Path: headers if you want to do this", for
example), is a different matter. If they want to implement any new
scheme _themselves_ of course they have to make _some_ changes to do
The suggestion _did_ only affect handling for Submitters that signed
messages and does not affect legacy systems that don't. Attention would
be drawn to the entity signing the message, which seems a desireable
outcome. This change ensures that Sender, as a reference header, would
remain static with respect to a signature reference. Forwarding would
otherwise tend to muddle certainty which header serves this function,
and the reason for considering a change in handling, again _only_ in the
case when signatures are applied by the Submitter.
We need to recognize difference between automated submission mail agents
which are what most forwarders are and actual case of user initiated
forwarding.
Dave has argued any entity that changes messages should be expected to
resign these messages or have the signature fail. There has been some
discussion as to how the results of signature validation gets relayed
when it gets resigned, but there is no expectation that message
signature survive beyond content changes. I argued for a diagnostic
header as a means for detecting what has changed, akin to header
tagging. Detecting what has changed in a header should be simpler than
determining what changed within the message body. A diagnostic header
should be able to do better within the body than a line count. The
diagnostic header should be able to evolve separately from the signature
scheme as well.
With user-initiated forwarding, all bets are off as to if the signature
should survive or not. If its full forwarding with content changes, then
I think new headers should be created and original ones (including
signature) should be discarded or put into Message-RFC2822 mime part.
It would be better to resign messages. You will always be left figuring
out what happened as a result of legacy message handling. It would be
clever to encapsulate the signed message, but this too requires changes.
Alternatively some users may want to use Resent- headers if original
message content is not changed. In my opinion, the original signatures
should in this case no longer be trusted because its basicly a new
message, i.e. any signature below the resent headers should be ignored
by verifying agent (unless its for purposes of some forensic analysis).
Just as with the case of an encapsulated message, why should this be
handled differently should the message content not have changed and the
signature is still valid, but has been forwarded by an unsigning entity.
Your comment seems to suggest that the signature should simply be viewed
as a new header. This would be a choice, but one that would seem to
integrate more slowly within existing mail handling.
I believe signature should be tied to the headers but it should not be a
requirement to be tied to any specific header, instead I think the sender
should have option in its policy records to indicate how the signature
they maybe creating is tied to the headers they are adding. I'll comment
on this later as its partially tied to the proposals I previously made at
SPF (i.e. "eh" - header equivalency modifiers).
The reference to policy, signature validation, etc must be tied to some
deterministic domain. It could be as a result of some binding within
the signature header (assuming there is only one). Some header tagging
and hash embedded within the signature header perhaps. It also seems
possible to define Sender header handling that would retain this as a
static header as well.
-Doug