Subject: [core] CoRE v/s Compressed HTTP

From: Vipul Gupta <[email-masked]>
Date: Wed, 30 Jun 2010 23:53:40 -0700

I've been following the mailing list discussion for some time now and
even after reading through draft-ietf-core-coap-00, I'm unable to see 
the compelling justification for a brand new protocol over using 
compressed HTTP as a starting point which is what Brian's original 
draft (http://tools.ietf.org/html/draft-frank-6lowapp-chopan-00) did. 

I can't help but feel an uneasy sense a Deja Vu. I'm reminded of the 
early days of the WAP forum which initially took the stance that 
"standard" Internet protocols were too heavyweight for phones and set 
about defining its own set of incompatible protocols. I'm particularly 
aware of the security work where the forum defined WTLS as a "wireless" 
version of TLS (the resuse of the TLS acronym seemed like a marketing 
ploy because the two protocols were incompatible and some of the 
incompatibilities introduced security vulnerabilities in WTLS). Our 
work at Sun Labs on SSL/TLS for small devices (Palm PDAs and subsequently
sensor nodes as small as the Berkeley mote[1][2]) showed otherwise. We 
demonstrated that one could profile SSL/TLS appropriately so it could 
still be used on the wireless devices of the day while maintaining 
compatibility with the large majority of existing deployments. Eventually, 
the right thing to do turned out to be the incorporation of Elliptic 
Curve Cryptography (ECC) the public key cryptosystem used in WTLS, 
into TLS (RFC 4492). This is now implemented in OpenSSL/Apache and 
Firefox, IE and offers meaningful performance benefits even for 
regular/unconstrained hosts [3].

I see strong parallels between adding ECC key exchange to TLS and 
defining header compression for HTTP. I wonder whether there would 
still be a place for COAP as currently defined if compressed HTTP 
were to become a standard. To me, the following seems like a better 
approach:

- Define header compression for HTTP which has the potential of being 
 very useful even for regular/unconstrained browsers and servers 
 interacting over TCP (Note that HTTP header compression is an 
 important component of SPDY, http://en.wikipedia.org/wiki/SPDY).

- Define a profile for compressed HTTP to be used in COAP, e.g. 
 subset of headers to be supported, restrictions on the size of 
 compressed messages so they can be carried over UDP, nailing 
 down the content of specific messages like subscriptions/
 notifications and check-in (as in the chopan 
 draft). The Webhooks approach (http://webhooks.org, 
 http://wiki.webhooks.org/RESTful-WebHooks) seems clean 
 and simple but certain aspects of subscriptions/notifications are 
 currently underspecified.

- Define how to carry compressed HTTP over UDP, e.g. handling of 
 retransmissions, congestion control, transaction IDs, etc

This approach seems to have several advantages -- it makes HTTP mapping 
easier, frees up the WG to devote its time to other important issues 
(nailing down the content of subscription/notification messages, 
discovery etc), and once regular browsers and servers adopt HTTP header 
compression (Chrome already seems to have some support for this) it 
makes true end-to-end security between COAP devices and the existing 
Web a real possibility.

Am I alone in feeling this way? What am I missing?

vipul
---
http://labs.oracle.com/people/mybio.php?uid=32495

[1] http://www.cs.plu.edu/courses/netsec/arts/coms.pdf
[2] http://cents.cs.berkeley.edu/retreats/winter_2005/SSL_on_motes.pdf
[3] http://labs.oracle.com/projects/crypto/ecc-ssl-ndss2004.pdf