[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [opes] draft-ietf-opes-smtp-security-01

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@xxxxxxxxxxxx] 
> Sent: Mittwoch, 6. Dezember 2006 19:35
> To: ietf-openproxy@xxxxxxx
> Cc: tony@xxxxxxx; 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
> 
>