Subject: Re: WG Last Call for secsh core drafts (halfway point).

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 26 Jan 2001 23:12:01 -0500

We're roughly halfway through the last-call period for the core
drafts:

	draft-ietf-secsh-architecture-07.txt
	draft-ietf-secsh-transport-09.txt
	draft-ietf-secsh-userauth-09.txt
	draft-ietf-secsh-connect-09.txt

I'd like to encourage additional review of the documents, especially
by implementors.  Based on the number of comments on the WG list
during the Last Call, either we're really close to "done" with these,
or nobody is paying attention.  (It's also conceivable that I may have
missed some comments in the flurry of discussion of newline
conventions)

I'd like to hope that we're almost done..

CURRENT ISSUES:

Discussion concerning the core drafts on the WG list since the start
of the last call has concerned two issues.

 - inconsistancy in architecture draft vs. RSA signature encoding

Niels Mo"ller <[email-masked]> pointed out that the architecture
draft recommends using mpint (a signed integer) for such values; the
transport draft uses a "string" containing an (unsigned)
representation.

Because of a lack of other voices on this issue I can't judge
where the WG consensus lies.

[personal opinion] if a change to the drafts is warranted, we should
fix this with an editorial change rather than a change to the wire
protocol.

 - possible improvements to X11 forwarding

Simon Tatham <[email-masked]> suggested some improvements to X11
forwarding.  Rough consensus appears to be that we shouldn't hold the
core drafts for improvements in the area.

WHAT HAPPENS NEXT:

Assuming nothing else is raised, we appear to be in good shape to
actually submit the drafts to the IESG.

If we decide to make an editorial change for Niels's issue, we can
republish new versions of the two drafts (architecture and transport),
and do an additional one week WG last call to review just that change.

Once the last call period expires, I then then submit the documents to
the security area directors for review; assuming it passes their
review, it then goes into a 2-week-long IETF-wide last call, and then
to the IESG for balloting.

					- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 26 Jan 2001 23:07:37 -0800

I raised an issue several months ago that I don't think ever got resolved.
The issue is how to define "partial flush" of the zlib compressed data
stream. I think the current definition is ambiguous, but I'm not sure how
to fix it. The problem is that there is a bug in the current zlib library
which requires more bits (consisting of empty blocks) to be outputed in a
flush than is necessary. If we were to define "partial flush" in the most
natural way (i.e. not taking into account this bug), someone may create an
secsh implementation that's not compatible with any secsh implementation
based on the current zlib.

I've reported this bug to the zlib maintainers, and they've promised to
fix it in a future release. Do we want to maintain backwards compatibility
and define "partial flush" in a way that satisfies the current buggy zlib?

---

From: Tatu Ylonen <[email-masked]>
Date: Sat, 27 Jan 2001 12:47:13 +0200 (EET)

I think we need to maintain backwards compatibility, or every Secure Shell
(both SSH1 and SSH2) client and server is going to break.

I wrote the original code that used the partial flush; unfortunately I am
not sufficiently familiar with ZLIB and the compression mechanism in
general.  I never thoroughly analyzed the exact bits it generated on the
wire.  When writing the spec I just took the easy way out and referenced
the ZLIB RFCs (1950 and 1951).

Could you (or someone else familiar with the internals of ZLIB)
please write a specification of what the partial flush really means in the
context of SECSH?  Something that could be put into the transport protocol
draft.

There is also the possibility of defining a new compression method (e.g.,
"zlib-2") which does not suffer from the bug.  The downside would be that
for a long transition period, compression would often be disabled because no
common algorithm was found (unless new implementations supported both).  I
don't know zlib well enough to really know what would be the best answer,
but I would be happy if we could avoid having a second zlib compression
method.

    Tatu

---

From: Wei Dai <[email-masked]>
Date: Sat, 27 Jan 2001 05:58:32 -0800

Here are my suggested definitions. First the non-compatible version, which
you may consider for "zlib-2". (An implementation that supports "zlib-2"
can also easily support "zlib" so it may be a good idea to have both.)
This definition has the advantage of being simpler and saving a few bytes
per packet:

A partial flush means that the current compressed block is ended and all
data will be output. If the current block does not end on a byte boundary,
an empty block is added to fill up the last byte.

Here's the compatible version:

A partial flush means that the current compressed block is ended and all
data will be output. One or more empty blocks are added after the
compressed block to ensure that there are at least 9 bits counting from
the start of the last Huffman code not coding for end-of-block to the end
of the packet payload.

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 27 Jan 2001 10:04:32 -0500

Ok.

[WG chair hat on]

I'd like to treat this as two separate issues:

1) we don't accurately describe what's on the wire (due to the zlib
bug).

This is serious and (IMHO) warrants a fix to the current drafts.
(noting the zlib bug).

2) we could do better on the compression.

One of my alter egos is a performance tweaker, so fixing this (by
creating an alternate zlib-2 compression method) has a definite
appeal.

At this stage in the game (for Proposed Standard), it's OK to toss in
new features without implementation experience, but I don't think we
want to delay the drafts until we get consensus on zlib-2; it might
also be wise to wait until someone plugs the new zlib release into a
secsh implementation before defining "zlib-2".

So, what we can do is create a separate zlib-2 draft, and when that
gets suitably mature fold that into the transport draft..

Comments?

					- Bill

---

From: Markus Friedl <[email-masked]>
Date: Sat, 27 Jan 2001 16:19:20 +0100

>  - inconsistancy in architecture draft vs. RSA signature encoding

this is not really a inconsistancy, since it's at least consistent
with the "ssh-dss" encoding.

there is one more issue:

i think that the text about 'magic cookies'
added in draft-ietf-secsh-connect-09.txt
should be removed again.

        As the user's shell is usually used to execute the subsystem,
        it is advisable for the subsystem protocol to have a "magic
        cookie" at the beginning of the protocol transaction to
        distinguish from arbitrary output from shell initialization
        scripts etc. This spurious output from the shell may be
        filtered out either at the server or at the client.

an implementation advise, as proposed by Jeff P. Van Dyke,
is more than enough.

if you don't want to remove this section, than at least the
last sentence should be changed to :

        This spurious output from the shell must be filtered out
        at the server.

because old and future clients should not be affected by
server implementation details!

-markus

---

From: Wei Dai <[email-masked]>
Date: Sat, 27 Jan 2001 15:42:21 -0800

> secsh implementation before defining "zlib-2".

I don't think there's really any need to wait. The risk seems very low
that if we define zlib-2 today it will turn out to be unimplementable or
ill-defined. In fact there is already an implementation of the zlib
compression format that doesn't suffer from the zlib bug, namely the one
in Crypto++ (http://cryptopp.com).

---

From: Wei Dai <[email-masked]>
Date: Sat, 27 Jan 2001 16:23:37 -0800

> the start of the last Huffman code not coding for end-of-block to the end

I looked at the zlib source code a bit more, and it seems the definition I
suggested above does not correspond exactly to what zlib does now. The
above definition may be sufficient to work around the zlib bug, but since
it's not what's actually implemented today, I can't be sure.
Here's a better definition:

A partial flush means that the current compressed block is ended and all
data will be output. If the current block is not a stored block, one or
more empty blocks are added after the current block to ensure that there
are at least 8 bits counting from the start of the end-of-block code of
the current block to the end of the packet payload.

---

From: [email-masked] (Niels M�ller)
Date: 29 Jan 2001 11:38:44 +0100

> creating an alternate zlib-2 compression method) has a definite

Another alternative may be to define zlib partial flush accordning to
Wei Dai's first definition, and add an implementation note saying what
current zlib-based implemtations need?

That would make the protocol simpler, while leaving to implementors
and user's to deal with zlib bug-compatibility and configuration
thereof.

> gets suitably mature fold that into the transport draft..

Sounds reasonable to me. If we feel that it is important to include
zlib-bug-compatibility negotiation in the general algorithm
negotiation.

/Niels

---

From: Martin Forssen <[email-masked]>
Date: Mon, 29 Jan 2001 12:47:18 +0100 (MET)

>> gets suitably mature fold that into the transport draft..

Why not define zlib-N where N is a digit between 0-9 and denotes the
desired compression level?

	/MaF

---

From: Tatu Ylonen <[email-masked]>
Date: Mon, 29 Jan 2001 22:13:49 +0200 (EET)

I considered this when originally designing SSH2.  However, the
compression level is basically a local policy issue of the sending side.
Also, I think I recall a little bit of experimenting and finding little
advantage (but much higher computational cost) in the higher compression
levels.

    Tatu

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Jan 2001 18:26:10 -0500

> advantage (but much higher computational cost) in the higher compression

for what it's worth, I've seen a similar analysis of time vs. space
for gzip -1 through -9 (a long time ago, shortly after gzip was
released).

The compression level seems like something best left under the control
of the sender; i don't think some folks will take too kindly to an
option which allows clients tell their servers to burn N times more
cpu on -9 level compression to squeeze out the last 0.1% of space..

					- Bill

---

From: Martin Forssen <[email-masked]>
Date: Tue, 30 Jan 2001 08:44:06 +0100 (MET)

On 29 Jan, Bill Sommerfeld wrote:
>> compression level is basically a local policy issue of the sending
>> side. Also, I think I recall a little bit of experimenting and
>> finding little advantage (but much higher computational cost) in the
>> higher compression levels.
> 

Ok, I just did a litle experimenting myself and found that indeed the
difference between -9 and -1 to gzip was indeed quite small (I had
expected the difference to be much bigger). So it does not seem worth
the hassle to define different compression levels. I therefore withdraw
my proposal.

	/MaF