Re: http+aes

Seems to me there's a bunch of confusion about the purpose and goals of 
this scheme.

 From what I can see, its sole purpose is to enable the communication of 
a key to a client so that it can decrypt content.  the URI-scheme 
basically is used to multiplex the key into the URI, and identify itself 
as such so that the userinfo part can be correctly interpreted.  After 
that it's just HTTP.

There's another way to achieve a similar thing, such as Progressive 
Networks did with RAM files.

Have the URI point to a small file which contains the information 
required - target URI of encrypted content, and key, encoding, and 
checksum for integrity.

The client clicks the link, this file comes down with a specific content 
type, which triggers processing.

No changes to intermediaries, no new scheme.  Just a new content type.

Downside is 1 more round trip to fetch the info, but I think the 
benefits would outweigh that, since you can then transport a lot more 
information than you'd otherwise have to squeeze into a userinfo part of 
a URI.  You get independent control of this information as well, and it 
can have a different life-cycle than just a URI would.

A lot less risk of leakage also, since the info could be fetched by 
https, and secured to the requestor (i.e. whoever is allowed to view the 
content).

In any case, relying on client behaviour for security is never going to 
give security, but it sounds like this isn't really the primary goal of 
this system.

Adrien


On 6/03/2012 2:26 p.m., Ian Hickson wrote:
> On Tue, 6 Mar 2012, Poul-Henning Kamp wrote:
>> The major risk is that people understand neither how little privacy this
>> buys them, nor how trivially easy it is to compromise that privacy
>> accidentally.
> It's not intended that users even know this is being used, so it doesn't
> really matter if they don't understand it.
>
>
>> The proffered strawman about copyright protection is not credible:
>>
>> You cut and paste the link, and anybody who receives it can view the
>> copyrighted object, and you have no idea who leaked it.
> This is not intended for a situation where you do not trust the
> recipients, indeed. There's not really any credible way to give someone
> content that isn't watermarked in some way if you don't trust them. If the
> content _is_ watermarked, then you probably can't usefully cache it in a
> CDN. If you can, then you can do so with this mechanism as well, it's an
> orthogonal concern.
>
>
>> Trying to get benefits from crypto while trying to hide the fact that it
>> is not there, does not work, if people don't know it is there, they
>> don't know that they have to be careful not to break it.
> Let's be honest, most users have no idea what crypto is, let alone that it
> is there. Even things as critical as TLS as used for HTTPS -- most users
> don't really know what's going on. If we're going to rely on users
> understanding crypto, we might as well give up now.
>
>
>> Another problem is that this scheme does not offer any integrity.
>>
>> Your malicius CDN could truncate your object and you would never notice
>> that the last 2 pages of the contract are missing.
> In practice, a CDN would not keep its business if it was damaging the
> content it was caching. This is a substantially different risk than the
> CDN (or a rogue agent within the CDN) just copying the content.
>
> There's no reason this mechanism couldn't be used with other generic
> integrity checking mechanisms, though.
>
>
>> Having been through the mill a couple of times myself, I can not
>> recommend strongly enough, that you try to get at least one
>> card-carrying cryptographer to go over the key-handling and the
>> cryptographic operations, before you try to standardize anything
>> involving a cryptographic algorithm.
> This isn't my first barbecue either.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

Received on Tuesday, 6 March 2012 04:59:40 UTC