RE: Benjamin Carlyle http 2.0 expression of interest

I didn’t understand your point 1. Are you saying that no one should be allowed to inspect messages if someone wants complete privacy and he has enabled end to end encryption?
I think there are cases in which authorities should be allowed to inspect and intercept  if they have sufficient reasons to do so.
There are mechanisms using which you could allow “valid” intermediaries to inspect messages even if end to end encryption (may be using TLS) is enabled/allowed for a user based on his preference.
However there has to be strong and appropriate reason for peaking into someone’s privacy….
Also we should be able to do simple header inspection for better traffic handling without going into content of the message/transferred data.

There is a difference between MITM attack and “valid” interception and a protocol should make arrange for decryption by third-party if that third party has proper authority to do so.

Best Regards,
Anil

From: fuzzybsc@gmail.com [mailto:fuzzybsc@gmail.com] On Behalf Of Benjamin Carlyle
Sent: Sunday, July 22, 2012 2:21 PM
To: ietf-http-wg@w3.org
Subject: Benjamin Carlyle http 2.0 expression of interest


This is an individual submission towards the http/2.0 protocol.
My background is mostly in highly available soft real-time m2m use cases for http, rather strict browser-centric or Web-centric use cases. Http/1.1 provides a good basis for these use cases but has a number of deficiencies I would hope could be corrected for the new protocol revision.

#1 Message level signatures
Transport level security provides privacy and non repudiation at the penalty of denying intermediaries the right to inspect messages and otherwise be involved in a transaction. Message level security measures could bring about specific benefits for http in relation to REST and practical use cases. For example:
A signed representation could be returned by a cache without introducing man in the middle attacks, particularly if the intermediaries are able to add their own metadata to an envelope that contains the original unmodified and signed body and headers from the origin server.
A signed request could eliminate the need for existing authentication mechanisms and allow a message to be authenticated without the need for additional round trips between client and server.
Signed messages could be inspected by firewalls to prevent requests being sent that contravene local policy.
An encrypted response that can be read only by its intended recipients could in theory even be returned to arbitrary clients without needing to first authenticate them.
I think that signatures would significantly simplify m2m use cases. Encryption may also be of use, although it is less important in my particular use cases.
Transport level encryption can work against goal of allowing intermediates to inspect and be involved in transactions.

#2 Canonical form or info set
The signature and encryption issues may be the tip of a larger canonicalization ice berg. HTTP has traditionally allowed new headers a level of freedom in defining both semantics and parsing rules. As we move forwards perhaps it is time to place some limits on this.

#3 Out of order responses and heartbeat capability
Modifying http to be able to make efficient use of a single TCP connection is I think a priority for many members of this list, and is something that SPDY has been specifically developed to address. I would like to expand on this with the specific notion of heartbeats to be able to reliably answer the question: Is my connection alive or dead? If the connection is dead the client will want to know as quickly as possible so that it can connect to a redundant instance of the server.
In my use cases I often want positive confirmation that my connection is still valid approximately every four seconds, plus assurances from intermediates that they are also seeing heartbeats. For long poll use cases this can be taken care of by requesting a short timeout in requests and for long database transactions a slow response can be replaced by an asynchronous interaction, but it would be helpful to have the server send regular updates on the processing status for a given request. A regular high priority OPTIONS * request may suffice to solve this problem.

#4 consider replacing internet media type identification model
A bit of a wishlist item, but mostly self explanatory. As far as m2m use cases go a typical company might need to mint dozens or more media types for internal use without coordination with the IANA, and it would be good to allow a url that refers to the type's specification or allow a combination of centrally registered tokens and urls as per RFC 5988's link relation registry.

#5 A must understand model
Currently if a new feature is added to http requests that must be understood servers the client must use a new http method to ensure that a server who does not understand will reject the request. Perhaps it is time to introduce a more refined model. My thinking is a must understand header that consists of tokens/urls stating special requirements the server must fulfil before accepting the message for processing. The client could include an additional header that indicates its own supported features to allow the server to tailor its own processing or potentially reject the request.

#6 An idempotent POST
It would be helpful to have a way to idempotently POST new state. My preference would be for the client to be able to supply a unique identifier as part of its request that can be used by the server to ignore repeated instances of the message, preferably as a uuid or guid in uri form or other unique uris.

That's probably enough of a wishlist for my first post to this list. Comments/criticism welcome.

Benjamin