On Tue, 21 Dec 2004, Douglas Otis wrote:
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.
I think we ran into situation of using different definitions of submitter.
In your definition you consider sumbimtter to be what I consider the sender,
i.e. its the entity that used used MSA to originally inject the message
into transport stream. In marid-submitter and responsible-submitter
drafts, the SUBMITTER is different entity and is basicly the system
last responsible for inejection the message but it may not necessarily
be the entity that is a sender or that sent the message to MSA - in the
marid-submitter, every forwarder is a SUBMITTER
I've a feeling you do not agree with that and I've a feeling Dave Crocker's
mail-arch may not agree with calling every forwarder a submitter either
either (but admitedly I have not had time to closely read that draft,
I'll try to do that over next couple weeks).
Dave Crocker has a role breakdown at:
http://brandenburg.com/specifications/draft-crocker-mail-arch-01.html
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.
That is what I thought - your submitter is what I call the sender.
(I'll note here that I've never felt that use of "Sender:" header by
mail lists is appropraite - I'd have felt much better if they have
chosen unique header, like say "Maillist-Sender")
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.
See, above the statement comes from assuming different definition of
submitter.
Not all domains will have equally stringent policies and thereby offer
more or less protections for the Originator.
I don't think we can judge everyone in the same light, especially not
all mail senders. As such I consider it good that certain flexibility
of which policies senders decide on be allowed and what I consider most
important is to agree on standard mechanisms for domain owner to express
those policies.
At the same time we must not force the recepient to accept email if it
does not agree with policies that sender has listed and things they are
too lax.
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.
I know, I've no problem with not talking about it here - somebody else
brought it up actually... I just don't like people who are now saying that
we can provide email security if say either SPF or DK verify - that does
not seem sufficient for me - its not either/or for me and I see it as some
kind of trick to have people think its ok to standartize mechanisms with
known technical flows that can not work for all situations to begin with.
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.
I do not agree and neither do many others including people at Cisco with
their IIM proposal. I'll note also that PGP and S/MIME signatures often
survive mail modifications (by some mail lists - other mail lists of
course dont act nice, but often these are the same mail lists that don't
act nice toward MIME in general).
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.
Again, I disagree, but see above.
I'll note also that the part of my own text you're replying to was talking
about mail modified directly by end-user to create new message. That is
substantially different then additions of footer text done by mail list.
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.
I looked at that concept as well actually in a different style (a speciaized
regex syntax for verification that data is substantially the same), I may
yet publish what I've come up with. But my current view of this is that if
digest (message hash) is included separately from the signature, it already
provides a way to see that content has changed and that separate data on
this will bring nothing new.
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.
This is new message, in current way it works MUAs, would not include any
headers from previous message, there is nothingto resign (only to sign
a new). I argue that it maybe of interest (primarily for forensic
analysis) if MUA as an option include previous headers for user
forwarded email and some do offer this option.
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.
Because its new message, it has (should have) new Message-ID, new person
now handles bounces (RFC2821 session parameters are new and do not survive
when its user initiated forwarding). We've discussed it at the end of
MARID when its been finally brought up that Microsoft has misundertood
the meaning and use of Resent- headers and we thereafter questioned
Pete Resnick on jabber (I finally understood it only couple days
thereafter after rereading everything - originally I just saw that
something seems wrong between how its descibed in different documents).
My opinion about Resent-* headers now is that its outdated way of doing
what can now be a lot better done by user being able to include original
forwarded message as Message-RFC2822 mime part. This means use of Resent
is basicly a historical way of doing it before MIME.
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.
I don't think its universally good to require signatures to be tied
exclusively to Sender header, but I certainly do think signature
validation should be tied to deterministic domain as you put it.
And yes possibility exists simply adding new data parameter into
signature itself which would indicate what header had the same email
address (or within same domain boundary) as signature signer. I'm in
fact currently considering this option.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net