RE: LateClearance content encoding

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

It is all arround a possible virus that could be transfered.

We could say that a client that supports this content encoding will delete and not execute the data if it does not receive the clearance but the error message even if the data itself is not encrypted.

But I am concerned that this is not sufficient and too dangerous. The client may write the data to a file and cannot guarantee for other parts of the operating system not to access that data before it gets a chance to delete it again.

It will it also make easier for an attacker to use vulnerabilities in the client's implementation to access the data which should not ne used.
For example the attacker could just be able to add the Accept header to the request, and the data is then transfered, the client does its job and is not aware of the "do not use the data" flag.

Maybe there are some other scenarios where the flag itself is sufficient so that encryption could be optional?

Martin

> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@xxxxxxxxxxxx]
> Sent: Wednesday, November 06, 2002 8:21 PM
> To: Martin Stecher
> Cc: ietf-openproxy@xxxxxxx
> Subject: Re: LateClearance content encoding
> 
> 
> It's a nice solution, but it's important to know what the problem is.
> 
> I'm unclear about why the data must be encrypted.  The only 
> point is to
> keep the enduser from using the data, so it would seem sufficient to
> just have the late clearance flag alone - let the client decide how it
> wants to handle data while it is in the uncleared state.  Why is this
> insufficient?
> 
> Hilarie
> 
>