[TLS] Stream multiplexing extension RE: SPDY / Next protocol negotiation

["Brian Smith" <[e-mail]>]

Adam,

Besides SPDY, the next protocol extension is useful for another case: Running HTTP, SMTP, and/or IMAP services on the same port (usually 443). For example, it could be used to make it difficult to tell if a user is sending (SMTP) or receiving (IMAP) email, if padding is done appropriately. I think this is a very valuable addition. It is hard to do without a TLS extension because HTTP is a client-speaks-first protocol, and SMTP and IMAP are server-speaks-first protocols.

My understanding is that SPDY will always require TLS, right? If so, then TLS w/ TLS compression + HTTP pipelining seem to offer most/all of the benefits of SPDY except (a) the simplified HTTP header parsing, and (b) the multiplexing. I don't really see the advantage of the HTTP header syntax changes considering the large amount of computation needed for (de)compression and (de/en)cryption. So, why not recast SPDY as a "canonical HTTP header lexical syntax" profile + HTTP pipelining + TLS + TLS w/ TLS compression + a TLS stream multiplexing extension?

IMO, a stream multiplexing extension would be generally useful because it frustrates traffic analysis, and it could be used for more effective padding than the minimal/inefficient padding that TLS CBC mode offers (simply multiplex a no-op stream along with your real data streams). Also, AFAICT, TLS doesn't provide any padding facility at all for stream (e.g. RC4) or AEAD cipher suites (AES-GCM in particular).

Regards,
Brian