Subject: Re: [TLS] Multi-Threaded Applications over TLS

From: [email-masked]
Date: Tue, 21 Apr 2009 09:34:30 +0100

>On Mon 20/04/09 7:02 PM , Nicolas Williams [email-masked] sent:
>On Mon, Apr 20, 2009 at 07:21:46PM +0200, Badra wrote:
>> 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.

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

Peter Gutmann did a reasonable analysis of SSH and TLS performance characteristics, showing some issues with SSHv2:

http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 21 Apr 2009 12:19:26 -0400

Well it doesn't HAVE to cost an extra round-trip, but I said that EVEN if it did it would be acceptable. If it doesn't cost that - so much the better!

----- Original Message -----
From: Nicolas Williams <[email-masked]>
To: Blumenthal, Uri
Cc: [email-masked] <[email-masked]>
Sent: Tue Apr 21 11:59:43 2009
Subject: Re: [TLS] Multi-Threaded Applications over TLS

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