Hi Hilary,
thanks a lot for your comments.
The purpose of the document is actually explained in the "Abstract" section:
Previous work has focussed on HTTP and work for SMTP is in progress.
These protocols differ fundamentally in the way data flows and it
turns out that existing OPES requirements and IAB considerations for
OPES need to be reviewed with regards to how well they fit for SMTP
adaptation. This document analysis aspects about the integrity of
SMTP and mail message adaptation by OPES systems and privacy and
security issues when the OPES framework is adapted to SMTP and lists
requirements that must be considered when creating the "SMTP
adaptation with OPES" document.
I am not so sure about your comments to section 3.3:
First, it is important that OPES is compatible with end-to-end encryption
in a sense that a sender can encrypt and/or sign a message for a recipient
and that
such an encrypted/signed message is able to pass OPES systems (principally -
if the policy
does not block completly). By encryption the sender can ensure that OPES
services
cannot scan the content and by signing the sender can provide a technique
for
the recipient to verify whether the content has been changed (by an OPES
system or by something else). That is all good.
As an additional option an OPES system can be designed to participate in the
encryption/signing process; I know that many people hate that but others
will like it
and it can make some sense, IMO.
A sender can for example ensure that only the sender and one dedicated OPES
service
can decrypt the message and by that ensure necessary malware scanning at a
gateway
plus protection against any other scanning.
Regarding your non-opes comment:
I agree, this sentence is confusing. Yes, the intent was to say that the
OPES service
makes a policy decision that causes the OPES processor to reject the message
such that
an incoming message cannot pass the client-centric OPES system.
For example a spam filter that rejects messages determined to be spam: the
receiver should
have a chance to configure the system such that it can receive the original
email to
prevent false positives.
Best regards
Martin
-----Original Message-----
From: The Purple Streak, Hilarie Orman
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Mittwoch, 6. Dezember 2006 19:35
To: ietf-openproxy(_at_)imc(_dot_)org
Cc: tony(_at_)att(_dot_)com; Stecher,Martin
Subject: RE: [opes] draft-ietf-opes-smtp-security-01
The draft really needs an initial paragraph stating the
purpose. It is a guide to security for desigers of services
for SMTP using OPES processors? A prototype "security
considerations" section for any OPES/SMTP protocol documents?
Or is it only for the purpose of "revisiting" the IAB
considerations? I'm confused about this, because the draft
mentions RFC3914 (OPES vs. IAB consideration) in its
introduction but only mentions RFC3837 (Security ... for
OPES) at the end as something with "generic" considerations.
So I think the draft positions itself as a refinement of
RFC3914, despite its generic title. The first paragraph
should explain this.
Section 3.3 was motivated by text in the introduction to
RFC3238. I have always believed that the IAB was seriously
in error when it wrote that paragraph, because it confuses
encryption with integrity and misuses the term end-to-end.
The result is an impossibility. To cope with this, the draft
MUST substitute the words "cryptographic message integrity"
for "encryption" in all cases and note that if the protection
is based on symmetric keys, then the problem of key sharing
is a grave security risk, but if the protection is based on
asymmetric keys, then the desired protection is possible.
Section 5.8 should note that section 3.3 is an interpretation
of the the most likely intent of the authors of RFC3238.
I think I've expressed confusion about this text before:
the receiver should be able to
indicate if he/she wants to receive a non-OPES version if the OPES
service would result in rejection of the email.
If this means that the OPES processor itself reaches a
"reject" decision, that's fine. But if it means that it
modifies the message in such a way that it violates some
other local policy and is rejected after it leaves the OPES
processor, then the text isn't fine. Please clarify.
Hilarie