Re: http+aes

On Mon, 05 Mar 2012 11:21:06 +0100, Julian Reschke <>  

> FYI:

This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO

* What are the use cases?

* Why is it better than using HTTPS? If the URL is sent over HTTPS you  
will very likely already have at least one persistent HTTP connection open  
to the server (assuming it is the same server) so establishing a new  
connection (same or different server) for this request is not going to  
increase performance. Even if no connections are open, for a properly  
configured server, reestablishing a SSL/TLS session is not going to take  
much longer (one extra roundtrip) and the entire request and response will  
be protected.

* What is the keymaterial? If the userinfo is the key, how is it encoded?  
Base64, hex, calculated (how?), or other format, and if so, where is the  
CTR nonce encoded? If userinfo is not the key, how is the userinfo used to  
obtain the the encryption key, and how is that information secured?

* If the keymaterial is intended for long-term usage by a single user,  
depending on storage methods, how is the keymaterial info migrated  
securely to a new client, either for parallel use in multiple clients, or  
system recovery?

* Given that this is probably going to be MITM vulnerable when used over  
plain HTTP, what should the client do if the URL is provided over HTTP (or  
included by reference in a document loaded over HTTP)? Refuse to perform  
the request, or go ahead anyway?

* How does this interact with other ongoing specification work, such as  
the Javascript Crypto APIs?

* How will this interact with clients that does not understand the URL  
scheme? It is quite possible that they will display the userinfo in the  
addressbar or the resulting error messages.

Yngve N. Pettersen
Senior Developer		     Email:
Opera Software ASA         
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01

Received on Monday, 5 March 2012 12:51:38 UTC