Re: Call for Adoption: Encrypted Content Encoding

On 1/12/2015 12:15 p.m., Roland Zink wrote:
> Am 30.11.2015 um 21:10 schrieb Walter H.:
>> On 30.11.2015 13:22, Amos Jeffries wrote:
>>> The point of this draft is the same. When anything is encrypted with
>>> intentio that the recipient acts on the decrypted content in ways
>>> other than saving it to a file - the sender emits the appropriate C-E
>>> header that says its crypted (and how). Such that the recipient can
>>> decrypt if/when it has the ability. 
>> in comparison to encrypted end-to-end encrypted E-mails, there is the
>> same problem; this draft is the same bad idea than the
>> publishing the public keys to the wide ...
>>
> 
> TLS is also end-to-end
> 

That is a false statement.

TLS is point-to-point. There is no requirement in TLS that point-B on
the conection be the origin server.

Very often in CDN network HTTPS it is actually not the origin server but
a TLS offloader / load balancer at least one hops in front of a whole
LAN or farm of origins.

One CDN I recently helped diagnose traffic bugs within had 8 distinct
connection hops from the frontend HTTPS terminating device to the origin
server. Over three separate TLS connections and a VPN  (non-TLS)
connection across two continents.



>> I don't say that the malware detection on client side is not as good
>> as that on any server side; I'd say,
>> that the chance to detect malware is better when it is not only at one
>> pont: the client;
>>
>> just think of the following case:
>>
>> someone has implemented this draft; that everybody downloading the so
>> uploaded data trusts the server owner ...
>> and it absolutely nonsense that the webadmin itself can't clearly open
>> the file natively on the server, because its encrypted ...
>>
>> data exchange is good, but this way its more than stupid;
>>
>> there doesn't exist any really USEFUL use case ...
>>
>>
> I don't understand the problem. The message is send from server A
> through server B to recipient C. B can't read the message. As long as C
> can determine the message is from A (and not B) this is the same as with
> TLS, isn't it?
> 
> That said it might wishable for TLS end users to contract a third party
> to check the messages before opening itself the messages.
> 

One use-case:

  Global service provider Not So Awkward offers cloud storage services
at a cheap price that nobody else can beat. Estonian Central Bank has
grown so large that it needs an external backup. It has the obvious
legal restrictions that prevent storing banking records unencrypted on
any third-party service. As well as the added problem that NSA cloud
services are not able to provide clear information or guarantees about
the specific location or safety of their storage servers.

 Since it is paying for the storage service EC Bank would like that
service to be useable as a full working alternative should its internal
systems suffer an outage. This means that clients be able to download
and use the objects stored by the NSA cloud directly from a banking web
portal (stored on another smaller but more trusted third-party) without
additional archival software being needed.

 The EC Bank decides to use C-E:aes to encode their backup content in
its native format with cryptographic keys that only the bank itself and
the individual clients are able to access on a per-object basis. But no
other party, including the backup cloud provider can access.


HTH
Amos

Received on Tuesday, 1 December 2015 14:02:53 UTC