ietf-mailsig
[Top] [All Lists]

Re: The end points are PEOPLE

2004-12-21 12:29:21


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.

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.

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!

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 recongize difference between automated submittion mail agents
which are what most forwarders are and actual case of user initiated 
forwarding. 

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.

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).

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).

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/


<Prev in Thread] Current Thread [Next in Thread>