Subject: [TLS] Multi-Threaded Applications over TLS

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 14:53:25 +0200

Hi all,

We have posted a document that describes "multi-threaded application"
multiplexing over a single TLS session.

Comments are welcome.
Best regards,
Badra

The Transport Layer Security (TLS) is the most widely deployed
protocol for securing network traffic.  It provides mutual
authentication, data confidentiality and integrity, key generation
and distribution, and security parameters negotiation.  However,
missing from the protocol is a way to multiplex single-application
multiple-stream applications that commonly use parallel connections
to the same logical and/or physical server application data.

This document describes a mechanism to multiplex single-application
multiple-stream over TLS.  It extends TLS to multiplex parallel
connections of a given application over a single TLS session,
avoiding additional delay related to the TLS/TCP session/connection
setup.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Apr 2009 11:40:02 -0500

> http://www.ietf.org/internet-drafts/draft-badra-tls-multiplexing-00.txt

Seems very similar in scope to SSHv2's multiplexing.

Have you looked at SSHv2, specifically RFC4254?  There have been
problems getting SSHv2 implementations to grow channel windows so that
the maximum available bandwidth can be used.  Have you looked at these
issues?

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 20 Apr 2009 19:53:49 +0300

> multiplexing over a single TLS session.

Hello,
 Is TLS the appropriate level to do this protocol? Couldn't it be over
TLS, or over any protocol that is being used at the moment? It looks it
has a broader applicability than just TLS.

regards,
Nikos

---

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 19:20:21 +0200

> has a broader applicability than just TLS.

Hi Nikos,

This could be done over TLS, but IMO, it is better to negotiate the
multiplexing functionality early during TLS Handshake and to share the same
code for several applications running over TLS. (An expired document
describes it over TLS draft-badra-hajjeh-mtls-04)

Best regards,
Badra

---

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 19:21:46 +0200

> the maximum available bandwidth can be used.  Have you looked at these

Hi Nicolas,

I agree, the document provides some of the RFC4254 services, but honestly I
am not aware of SSHv2 problems. Any link, help or suggestion to avoid these
issues are appreciated.

Best regards,
Badra

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Apr 2009 11:27:14 -0600

> has a broader applicability than just TLS.

In the XMPP community we are interested in something similar: the
ability to multiplex multiple domain-to-domain streams over a single
encrypted connection. Joe Hildebrand and I plan to write up at least a
requirements I-D about that soon. It's not yet clear to me if our use
case is in scope for draft-badra-tls-multiplexing.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Apr 2009 13:02:45 -0500

> am not aware of SSHv2 problems. Any link, help or suggestion to avoid these

A comparison of your proposal to RFC4254 would be useful: what are you
doing differently from SSHv2 and why.

Here's one link regarding SSHv2 and high performance networking:

http://www.psc.edu/networking/projects/hpn-ssh/

I'm not sure that there's anything wrong with the actual protocol
though.  There's no way to reduce a channel's window other than by not
adjusting it for received data, but I'm not sure that that's a problem.
Of course, I'm not sure anyone is actually trying to mix interactive,
small packet traffic with bulk data transfers in an high performance
networking environment...

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Apr 2009 11:33:41 -0700

At Mon, 20 Apr 2009 14:53:25 +0200,
> multiplexing over a single TLS session.

Are there any IETF WGs who are interested in TLS providing this
functionality?

-Ekr

---

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 20:51:06 +0200

> Are there any IETF WGs who are interested in TLS providing this

Hi Eric,

I think the transport folks could be interested. They have concerns with bad
congestion control properties of the massive parallel connection practice in
contemporary web browsers.

Best regards,
Badra

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Apr 2009 13:55:03 -0500

> contemporary web browsers.

So this is about HTTP?  Or do you have other applications in mind as
well.

I think there are fairly few Internet protocols that could benefit from
this (e.g., IMAP, LDAP -- these don't need to multiplex data streams as
they are already capable of multiplexing their operations), but HTTP
certainly seems like one of those that could.  SMTP might also be able
to use multiplexing as a way to keep a single connection open without
having to queue small messages behind large ones.

Nico
--

---

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 21:27:12 +0200

> So this is about HTTP?  Or do you have other applications in mind as

No, I just gave an example. It is about any application (over TLS) that
doesn't provide connection mutiplexing.
Best regards,
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Apr 2009 12:41:54 -0700

At Mon, 20 Apr 2009 20:51:06 +0200,
> contemporary web browsers.

I have a fair amount of skepticism about the relevance of this application:

1. My understanding is that the browser manufacturers consider the
   transport impacts (higher link share utilization, no head of
   line blocking) of multiple connections to be a feature, not
   a bug, regardless of what the IETF Transport Area thinks.

2. Just thinking about how, e.g., Apache is architected, it
   seems to me that making use of this functionality would
   likely entail fairly substantial modifications to the Web server
   in many cases. 

3. Given that most Web traffic happens not over HTTPS, I would expect
   that there would be much more interest in a solution which
   worked above the TLS layer and therefore would work for all
   Web traffic.

Has anyone from the Web community expressed interest in this feature?

-Ekr

---

From: Dean Anderson <[email-masked]>
Date: Mon, 20 Apr 2009 16:17:35 -0400 (EDT)

I think HTTP request multiplexing is definitely a good idea, especially
for things like ajax, which sometimes start multiple TCP connections on
the server with all the overhead or else have to be serialized. I
definitely encourage your idea, but I think it should be independent of
TLS.  I don't think its a good idea to do this at the TLS layer.

		--Dean

On Mon, 20 Apr 2009, Eric Rescorla wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Badra <[email-masked]>
Date: Mon, 20 Apr 2009 22:23:16 +0200

> Has anyone from the Web community expressed interest in this feature?

Eric, honestly I don't see why all these questions. The document is posted
since only 7 hours, and I didn't contact offline any persons "off-line" for
their comments.

Best regards,
Badra

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Apr 2009 22:37:20 +0200

> doesn't provide connection mutiplexing.

When I read the draft, I was thinking that it would be a useful
technique for VPN implementations that just want to set up one TLS
channel to the VPN server and then multiplex other channels through that
primary channel.

There is OpenVPN which is based on TLS, but it uses a rather ad-hoc
protocol [1] to implement a VPN.  A more standards-aligned way would be
to implement a VPN using TLS (or even DTLS?) together with multiplexing.

/Simon

[1] http://openvpn.org/index.php/documentation/security-overview.html

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Apr 2009 16:00:33 -0500

> since only 7 hours, and I didn't contact offline any persons "off-line" for

I do.  Eric is quite right to point out that retrofitting existing apps
to use this facility may be difficult to the point that it won't happen.
If it won't happen then why do it?  Also, Eric's interest in whether
there is IETF interest in this for use in Internet protocols is
important to determining how much interest TLS WG (and other)
participants may have.

I also agree that this should be a separate layer, but negotiation of it
in TLS handshakes is useful as a way to start that layer sooner rather
than having to have an application-layer round-trip to negotiate its
use.

Nico
--

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 20 Apr 2009 23:57:16 +0200

Dear all,

you can use SCTP as a transport protocol and use DTLS/SCTP. This
provides you with multiple streams (message order in each stream
is preserved) but the head of line blocking between the streams
is minimized.

Best regards
Michael

On Apr 20, 2009, at 7:27 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknssHIACgkQNL8k5A2w/vxkKACgjym7ECIL4ntl/45SBbRQEo05
> 1+EAn2IsB/kkkYd/bEmL5gDqwku6VTck
> =f4Xx
> -----END PGP SIGNATURE-----

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Apr 2009 15:05:50 -0700

At Mon, 20 Apr 2009 22:23:16 +0200,
Badra wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Eric, honestly I don't see why all these questions.

Uh, because I'm trying to figure out whether this is something
worth doing and the high order question for that determination
is whether anyone wants it?

-Ekr

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 00:18:37 +0200

On Tue, Apr 21, 2009 at 12:05 AM, Eric Rescorla <[email-masked]>wrote:

> > On Mon, Apr 20, 2009 at 9:41 PM, Eric Rescorla <[email-masked]
> >wrote:
> >
> > >

No problem.
Best regards,
Badra

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 00:19:39 +0200

Nikos, Badra,

As an aside, the mobile DTLS also provides multiplexing, but that feature was considered a separate topic so will be brought forward later.

Mapping threads into sessions might prove applicable for mobi-d as well.

Kind Regards,
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Nikos Mavrogiannopoulos
Sent: 20 April, 2009 09:54
To: Badra
Cc: [email-masked]
Subject: Re: [TLS] Multi-Threaded Applications over TLS

> multiplexing over a single TLS session.

Hello,
 Is TLS the appropriate level to do this protocol? Couldn't it be over TLS, or over any protocol that is being used at the moment? It looks it has a broader applicability than just TLS.

regards,
Nikos

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 20 Apr 2009 20:48:17 -0400

(After reading the whole exchange) I think that Nikos is right - it seems a useful thing, but it does not belong to TLS protocol. Should be done at the higher layer (and if it costs one more round-trip - I'd say it's a fair price for design sanity).

On 4/20/09  12:53 , "Nikos Mavrogiannopoulos" <[email-masked]> wrote:

Hello,

regards,
Nikos

--
Regards,
Uri
<Disclaimer>

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 09:50:24 +0200

Hi Badra,

I see that you also have a patent application related to multiplexing
several data streams inside one TLS connection:

http://v3.espacenet.com/publicationDetails/biblio?adjacent=true&KC=A1&date=20071121&NR=1858224A1&DB=EPODOC&locale=en_EP&CC=EP&FT=D

Is this related to draft-badra-hajjeh-mtls and/or draft-badra-tls-
multiplexing? (That is, should we expect an IPR disclosure soon?)

Best regards,
Pasi

> From: Badra
> Sent: 20 April, 2009 15:53
> To: [email-masked]
> Subject: [TLS] Multi-Threaded Applications over TLS
> 
> Hi all,   
>
> We have posted a document that describes "multi-threaded
> application" multiplexing over a single TLS session.
>
>  Comments are welcome.  Best regards, Badra   The Transport Layer
>Security (TLS) is the most widely deployed protocol for securing
>network traffic.  It provides mutual authentication, data
>confidentiality and integrity, key generation and distribution, and
>security parameters negotiation.  However, missing from the protocol
>is a way to multiplex single-application multiple-stream applications
>that commonly use parallel connections to the same logical and/or
>physical server application data.
>

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 09:56:45 +0200

Nicolas Williams wrote:

> I also agree that this should be a separate layer, but negotiation
> of it in TLS handshakes is useful as a way to start that layer
> sooner rather than having to have an application-layer round-trip to
> negotiate its use.

BTW, such separate layer already exists: the SSH Connection Protocol
in RFC 4254 (although the document has "SSH" in the title, the
connection protocol is really quite separate from the rest of the SSH,
and you could run it over any reliable transport -- including TLS).

Best regards,
Pasi

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 21 Apr 2009 21:04:26 +1200

>Seems very similar in scope to SSHv2's multiplexing.

Ugh, which should serve as a horrible warning to others, not something to be
emulated.  See the (now somewhat dated) "Performance Characteristics of
Application-level Security Protocols",
http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf, specifically section
6.2, "The SSHv2 and SFTP Performance Handbrake", for details.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 21 Apr 2009 21:23:53 +1200

>I have a fair amount of skepticism about the relevance of this application:

There's a fourth reason:

4. HTTP 1.1 pipelining has been around for nearly a decade, and if browser
vendors really cared about this issue all they'd need to do is turn pipelining
on (Firefox has it disabled by default, MSIE and Opera AFAIK have it enabled).
There was a paper published some years ago (sorry, no idea what the title was
any more) which showed that it wasn't necessarily faster over a high-speed
connection (some of the earlier experiments were run with dialup and other
slow, high-latency connections where setup and teardown were expensive).  So,
for the case of HTTP use, it seems entirely unnecessary, the mechanism to deal
with this is already present in pretty much every browser, and even then
there's no sign that browser vendors will actually use it even though it's
available.

Peter.

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 11:34:53 +0200

> multiplexing? (That is, should we expect an IPR disclosure soon?)

Hi Pasi,

I submitted the IPR disclosure.
Best regards,
Badra

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 15:33:36 +0200

On Tue, Apr 21, 2009 at 2:48 AM, Blumenthal, Uri <[email-masked]> wrote:

> (After reading the whole exchange) I think that Nikos is right – it seems a
> useful thing, but it does not belong to TLS protocol. Should be done at the
> higher layer (and if it costs one more round-trip – I’d say it’s a fair
> price for design sanity).
>

> Nicolas Williams:

Well, the first option is defined in the document, whereas the second is
described through draft-badra-hajjeh-mtls-05.

Best regards,
BHadra

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 15:40:31 +0200

> and you could run it over any reliable transport -- including TLS).

RFC 4254:
-  cannot operate over unreliable transport such as UDP.
-  couldn't be used as it is, you should assign a TCP port to run it over
TLS.

Best regards,
Badra

---

From: Dean Anderson <[email-masked]>
Date: Tue, 21 Apr 2009 10:13:56 -0400 (EDT)

What is the IPR disclosure number. Searching doesn't produce anything.

Search result on draft-badra-tls-multiplexing, "Multiplexing 
Single-Application Multiple-Connection over TLS"
	No IPR disclosures related to draft-badra-tls-multiplexing have 
been submitted

Thanks, 

		--Dean

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 17:35:53 +0200

Hi Michael,

> As an aside, the mobile DTLS also provides multiplexing, but that feature
> was considered a separate topic so will be brought forward later.
>

I can't see how mobi-d can multiplex applications' channels.

> Mapping threads into sessions might prove applicable for mobi-d as well.

Well, but I don't need mobi-d to do so.

Best regards,
Badra

---

From: Badra <[email-masked]>
Date: Tue, 21 Apr 2009 17:36:38 +0200

Hi Dean,

It take one business day (I submitted it this morning)
Best regards
Badra

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 10:50:11 -0500

> -  cannot operate over unreliable transport such as UDP.

First let's establish that we need that.  SCTP comes to mind (and has
been mentioned already).

> -  couldn't be used as it is, you should assign a TCP port to run it over

Negotiation is a problem no matter what.  With TLS you happen to get a
place to do the negotiation early on (i.e., in the handshakes).  But as
has been pointed out, the one example you gave of a protocol that could
use this (HTTP) often runs without TLS, in which case you're back to
having to specify how this layer gets negotiated.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 10:59:43 -0500

On Mon, Apr 20, 2009 at 08:48:17PM -0400, Blumenthal, Uri wrote:
> (After reading the whole exchange) I think that Nikos is right - it
> seems a useful thing, but it does not belong to TLS protocol. Should
> be done at the higher layer (and if it costs one more round-trip - I'd
> say it's a fair price for design sanity).

Uri,

I agree, but I don't see why it should cost one more round-trip.
Piggybacking application-layer negotiations on client Hello/handshake
messages seems to me like quite a reasonable thing to do.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 10:58:00 -0500

> 6.2, "The SSHv2 and SFTP Performance Handbrake", for details.

I don't believe that handbrake exists other than as an implementation
artifact.  It's perfectly reasonable to have large channel windows, and
even to grow the channel windows so as to avoid having to ever wait for
an ACK.  The key is to grow the channel window to a point where the
sender never waits for an ACK before sending the next packet.

The problem is that the receiver doesn't know if the sender is ever
waiting -- except by heuristics involving a) detecting bulk (multiple
max sized packets), and b) timing of incoming packets before and after
growing the window to see if growing the window helps bandwidth, all of
which is a pain.  We could probably fix this by having a channel request
by which the sender can advise the receiver that the sender is often
waiting for window adjustments (ACKs).  The HPN OpenSSH patches don't
make the window that dynamic, IIRC, but they do make it dynamic and get
better performance, thus proving the point.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Apr 2009 17:06:58 -0700

>It take one business day (I submitted it this morning)

<https://datatracker.ietf.org/ipr/1137/>

<https://datatracker.ietf.org/ipr/1136/>

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 23 Apr 2009 18:38:17 +1200

Nicolas Williams <[email-masked]> writes:

>artifact.

I agree, it's purely an implementation artefact.  On the other hand security
bugs in software don't exist other than as implemetation artefacts either, but
they're not going to go away if you ignore them.  The problem in this case
it's that it's a design for which the straightforward implementation (and even
many not-so-straightforward ones) produce very bad performance, and you need a
very carefully designed and coded implementation, and preferably the same one
at both ends of the link, to avoid problems.

>It's perfectly reasonable to have large channel windows, and even to grow the
>channel windows so as to avoid having to ever wait for an ACK.

No, that doens't work either, because my implementation does it and other 
implementations break in various unuusal ways once the window gets too large 
(there's a particular error message from OpenSSH which I can't recall at the 
moment that you can google for to see that other implementations run into the 
same problem).  More implementation artefacts there.

>The HPN OpenSSH patches don't make the window that dynamic, IIRC, but they do
>make it dynamic and get better performance, thus proving the point.

OTOH simply setting a huge-size window (assuming you don't run into one of the
implementations that exhibit artefacts :-) has the same effect.

The real problem though is that this is a fundamentally unsound design.  If
you put in a considerable amount of time and effort and whatever's at the
other end has done the same and if you're lucky enough, it won't be so bad,
but the default leads to quite poor performance.  From the SSH experience,
most implementations are going down the default path...

Peter.