Subject: [TLS] draft-badra-hajjeh-mtls-00.txt

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Nov 2005 20:55:17 +0200

I promised in the TLS WG to review this draft, so here are my
comments.

Firstly as someone else pointed out after the meeting, there is really
no reason to do any modifications to TLS to provide that kind of
multiplexing support, this all could simply be done in an application
layer doing normal port forwarding style connections multiplexing
multiple port forwardings inside one TLS tunnel.

There is nothing in the draft that I can find that would tie the
multiplexed streams to the TLS exchange itself, i.e. the applications
cannot really even see they are multiplexed over TLS tunnel.

The whole draft seems to be adding similar feature that is in the
secure shell, i.e. port forwarding (and if I understood correctly this
is local to local port forwarding, so more limited than what is in
secsh). See draft-ietf-secsh-connect-25.txt section 7. It does not
take account some of the issues of the forwarding.

I didn't really understood if it has a way to dynamimcally create and
cancelo those forwardings or not. Also didn't see if it supports
runnig multiple streams over same ports, i.e. if you forward port 25
from your laptop throgh tls tunnel to smtp port (250) of the mail
server, do you allow multiple connections sharing that same forwarding
at the asme (i.e. send multiple mails simultaneously).

As far as I understood there is no flow control in the streams. That
kind of feature is mandatory in case you put multiple streams inside
one stream, and that flow control MUST be per stream.

The common problem happening with ssh1, which didn't have this was
that you forwarded 2 services over the same ssh connection. The first
one was sending data to some service all the time, and then when the
destination server decided, that it does not want to read data right
now, there was no way to tell that to the other end of the tunnel, so
the sender would stop sending data. At some point all the buffers in
the destination end filled up, and the only way it could use to stop
the other end sending data was to use flow control on the
ssh-connection itself, i.e not reading any more data from the ssh TCP
stream. This also stopped all other forwarded connections running on
the same session..

SSH2 fixed this including flow control to each channel separtely, i.e.
the receiving end of the channel can say that other end is only
allowed to send xx bytes of data, and then it must stop. When the
receiveing end managed to send those data forward to the final
destination, it would again say to sender ssh that now we are ready to
take xx bytes of more data and so on.

The draft needs quite a lot more work to be usable, and at least for
me it was very hard to understand how the protocol actually worked
(thus it might be that I completely misunderstood it).

On the other hand secure shell is already doing exactly what I
understood what it is trying to do, and it is one of the most common
use scenarios of the secure shell already, so I do not know if we want
to have another way to do exactly same thing in TLS. 
-- 
[email-masked]

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

---

From: badra <[email-masked]>
Date: Thu, 17 Nov 2005 11:09:49 +0100

Dear Tero,

Thank you very much for your revision. Sorry for this late replay, some 
comments are in-line...

>multiple port forwardings inside one TLS tunnel.

Adding an extension to TLS is not really a modification, particularly 
when the machine-state of the protocol, the handshake and the record 
protocols remains unchangeable.
Moreover, MTLS is transparent to the application except that the 
application will connect locally to a specific port reserved for MTLS, 
and it is the MTLS's job to deliver data to the application on the other 
side.

>cannot really even see they are multiplexed over TLS tunnel.

The application will be configured to forward data to the mtls local 
port, specifying the destination address (IP address or whatever). 
However, the actual version of the draft does not precise how to do 
that, and implementation note should be sufficient. We tried to keep the 
characteristic of TLS concerning the transparency and the application 
behavior.

>take account some of the issues of the forwarding.

I read the secsh draft and AFAIK, it is a set of signalling messages 
exchanged between the multiplexing processes over the SSH session. In 
the MTLS case, the negotiation is done during the handshake phase, which 
reduces the chance to the entities to say more about their voluntaries 
concerning some features such as packet size. Nevertheless, it could be 
possible to add some signaling messages at the MTLS layer to allow more 
options for the entities.

In the first version on this draft, we are focused on local Port 
forwarding with TLS. So, some issues like IP binding are not treated 
till now.

>at the asme (i.e. send multiple mails simultaneously).

Once the Handshake phase has been established, actual version does not 
allow creating or cancelling those forwarding applications. Because it 
is related to the TLS Extensions in creating and canceling new 
extensions (rfc 3546). Concerning the multi-mail, each mail will be sent 
aver a different local port, so each mail will be encapsulated in mtls 
packets, which are distinguished by the local port.

>take xx bytes of more data and so on.

Each connection will have local and destination ports and will be 
identified by that at the MTLS layer. So I don't see why it must be per 
stream? Even though we cited that using of stream IDs should be a 
generic mode, but how can we do it with the MTLS context?
As I cited before, if we want to add more features such as managing data 
length transportation, we should add some signalling messages at the 
MTLS and keeping it at the transport layer, instead of the application 
layer.

TLS does not allow sending signaling messages after the Handshake. Thus, 
a flow control can be implemented when mtls handshake in negotiated 
(i.e, a new field in the MTLS structure message).

>to have another way to do exactly same thing in TLS. 

I agree that the draft needs more works. However, some mechanisms like 
preshared keys were also defined by several security protocols before 
they were defined by TLS. And I thing it is more appropriate to have a 
maximum number of security services using TLS.
 
Best regards,
Badra

---

From: badra <[email-masked]>
Date: Thu, 17 Nov 2005 18:35:55 +0100

Tero Kivinen writes:

> badra writes:
> So is usage is identical what secure shell is doing today.

Hmmm, it provides the same services..., but there is no problem to 
borrow from SSH if we want really to add port forwarding to TLS. 
However, it is not the only way (plz see below).

>> ...
>
>
> Why the protocol needs to be on the TLS level? Why cannot it be simply
> application level program running multiplexing protocol over normal
> TLS channel?
>
> ...
>
>> stream?
> Because you end up in problems if you do not do that. If you do not
> have per stream flow control the only way to do flow control is to do
> it for the whole TLS stream, which means all the connections are
> blocked.
>
> For example say you have 2 connections run over the forwarded channel
> one to IMAP and another to the SMTP. Now you start sending some huge
> mail over the SMTP channel. The packets are trasmitted over the TLS
> channel to the remote end, and the remote end transmits them over
> local socket to the SMTP server. The SMTP server decides to start
> doing virus check on the first 5 kilobytes of the email it has already
> received (before reading the rest of the 100 MB email in). It stops
> reading the local socket coming from the TLS server. After few more
> kilobytes the local buffers in those sockets fill up and the writes to
> the local socket connected to the SMTP server from the TLS server
> blocks. The SMTP client is still sending data from the remote machine,
> and that traffic is coming over the TLS stream. The TLS server do not
> have any other way (as far as I know) to block that one stream of
> traffic than to stop reading the whole TLS socket, i.e. stopping all
> traffic going on the TLS stream.
>
> This also include other streams run over the same TLS connection, i.e.
> the IMAP etc connections. Now if the SMTP server never wakes up, the
> user has no other option than to discard the whole TLS connection
> which includes other channels too.
>
> Because of this you DO need per stream flow control.

There is no difference, in my opinion, to implement it at transport or 
application level.
In the case of transport level, your server will listen on a specific 
port, and in the case of application one, your application need to 
connect to a port running over TLS.

My point was to negotiate application types via a TLS extension and do 
not wait for the multiplexing protocol to do it once the handshake has 
been established. In other words, channel's opening is initialized 
implicitly during the handshake phase.

However, I agree that stream flow control will be required. But I don't 
think we are going to use the secsh method: let's assume that for each 
packet send by the MTLS client through an arbitrary channel, an 
acknowledgement (if the server has no data to write) will be sent by the 
MTLS server to inform the client that MTLS server is ready to read more 
data (a litte bit of data is sent...). Certainly this is not sufficient 
if we don't control the maximum data length that the entity is ready to 
read. Accordingly, both entities should negotiate the maximum packet for 
each application they want to run and this during the Handshake phase.

During the data exhange phase, the entity may be not ready to treat data 
with length larger than the maximum length negotiated during the 
Handshake phase. In this case, the acknowledgement packet must contain 
the appropriate length the receiver is ready to read. And if the local 
buffer fill up, no acknowlodgment packet will be send.

Do you agree with that?
(BTW, What will the server do if your scenario will happen in the case 
of an ordinary SMTP over TLS?)

> I disagree here quite a lot. It would be trivial to write application
> running over TLS channel that can do stream multiplexation and flow
> control properly without any need to change or add anything to the TLS
> level.
>
> As the applications using needs to be changed anyways (i.e. connect to
> the local socket instead of the remote socket, i.e. mostly
> configuration change) it does not really matter if they connect to the
> MTLS server or some application running over TLS protected stream. 

I would like to say that the actual document is 00 version and it is not 
the only way to do data multiplexing over TLS. And it will not be a 
problem to choose between application and transport layers if we want 
really to integrate data multiplexing over TLS.

Best regards,
Badra

---

From: badra <[email-masked]>
Date: Mon, 21 Nov 2005 17:36:23 +0100

Tero Kivinen writes:

> badra writes:
>
>> ...There is no difference, in my opinion, to implement it at 
>> transport or application level.
> Big difference is that if you do it on the TLS level you need to make
> TLS extensions. If you do it on the application layer, you simply need
> to define protocol which can be used over any channel (or simply reuse
> existing protocol, like secure shell connection layer).

I don't think that system administrators would like to maintain two 
security protocols up to date if TLS alone can offers these security 
services alone. Moreover, ref3546 was defined to be used and to define 
new extension features. However, the document needs to re-use some 
ssh-connexion's features (which are tcp multiplexing functions) to 
manage window size, etc.

The extension defined in the document is to be more clarified and it is 
defined to negotiate what the client and the server do support as stream 
types. If it is defined at the application layer, I have to define some 
signalling and error messages and to send them each time they want to 
open a new connexion or to verify if the other end support an arbitrary 
stream. In this way the link is established between the draft and TLS.
However, the window size could be initialized by each side by adding its 
value to the extension 's fields, and for each new connexion, a message 
is sent to initialize its window sender. The window size's control as 
defined in "ssh-connexion" may be used. However, I think the window size 
is able to grow up due to (implicit or explicit) acknowledgment messages 
(if I am correct). In this case, for each packet an acknowledgment will 
tell the sender about the next packet size to be sent to the receiver. 
And I think it is not related to the bandwidth, it is related to, among 
others, the socket's memory length.

>> ...
>>
> The question is do we want to integrate data multiplexing to TLS. I do
> not see any point of doing that.

The pros and cons may not have their end. But I would like to resume that:

- ssh-connexion is related to SSH
- mtls is based on TLS Extensions so we can optionally negotiate it. The 
actual document's version required more work to do.
- define a port forwarding at the transport layer could be more 
advantageous because of reducing the definition and the use of signaling 
and error messages.
- some property solutions doing VPN by running everything through HTTP 
whereas SSH does it over reliable transport protocol. It could be 
possible to have a comon mechanism that allows port forwarding over 
TLS/TCP as long as over DTLS/UDP (SSH runs over reliable transport), 
without re-write the applications.

Best regards,

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Nov 2005 13:03:14 +0200

> packets, which are distinguished by the local port.

So it allows multiple local ports over one remote ports even after the
handshake. That was not really clear from the document.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Nov 2005 11:47:47 +0200

> However, it is not the only way (plz see below).

I do not see any reason why we should have yet another protocol do to
the same thing, instead of using very widely used protocol already
doing that.

I assume you next suggest that telnet should be expanded to support to
transfer of www-pages instead of http...

> each application they want to run and this during the Handshake phase.

To get any real performance over the streams, you need similar window
code that is used both in TCP and in secure shell. And the window
sizes needs to be able to grow over the time. For example first ssh2
implementations used fixed window size, but that resulted quite bad
performance when transferring lots of data, so it was needed to add
code that will allow the window size to grow if it detects high
bandwidth transfer. On the other hand it does not want to use big
window size all time, as it just consumes too much memory.

> buffer fill up, no acknowlodgment packet will be send.

I suggest you read for example the secure shell connection layer and
see how it is doing that. On the other hand I do not still think we
should be doing this kind of protocol on this level. 

> of an ordinary SMTP over TLS?)

In case of the ordinary SMTP over TLS there is no problem, as TCP do
provide the flow control, and the whole TLS channel is stopped.
Because there is no other traffic going over the same TLS stream there
is no problem. The problem only appears when you start multiplexing
multiple streams to same TCP/TLS stream.