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

"Brian Smith" <brian@briansmith.org> Tue, 02 February 2010 17:37 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 9E69B3A6828 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 09:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id rCkf4h5QyaD8 for <tls@core3.amsl.com>; Tue, 2 Feb 2010 09:37:23 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net []) by core3.amsl.com (Postfix) with ESMTP id 93C203A672E for <tls@ietf.org>; Tue, 2 Feb 2010 09:37:23 -0800 (PST)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA7D4509DB; Tue, 2 Feb 2010 12:37:55 -0500 (EST)
From: "Brian Smith" <brian@briansmith.org>
To: "'Adam Langley'" <agl@google.com>
References: <001901caa3e4$c0363750$40a2a5f0$@org> <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com> <000a01caa423$92dc1d30$b8945790$@org> <a84d7bc61002020856m24f4975bib5dbc0073a0bfbfc@mail.gmail.com>
In-Reply-To: <a84d7bc61002020856m24f4975bib5dbc0073a0bfbfc@mail.gmail.com>
Date: Tue, 2 Feb 2010 11:37:56 -0600
Message-ID: <000b01caa42e$7761f600$6625e200$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkKLcJ7d2NA02bRVuGZ+F2oNXp1AAApPxg
Cc: tls@ietf.org
Subject: [TLS] Stream multiplexing extension RE: SPDY / Next protocol negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2010 17:37:24 -0000


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).