Subject: I-D ACTION:draft-ietf-secsh-transport-18.txt

From: [email-masked]
Date: Thu, 03 Jun 2004 15:59:47 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Transport Layer Protocol
	Author(s)	: T. Ylonen, C. Lonvick
	Filename	: draft-ietf-secsh-transport-18.txt
	Pages		: 29
	Date		: 2004-6-3
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
This document describes the SSH transport layer protocol which
typically runs on top of TCP/IP.  The protocol can be used as a
basis for a number of secure network services.  It provides strong
encryption, server authentication, and integrity protection.  It
may also provide compression.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm
are all negotiated.
This document also describes the Diffie-Hellman key exchange
method and the minimal set of algorithms that are needed to
implement the SSH transport layer protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-18.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-transport-18.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-transport-18.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Damien Miller <[email-masked]>
Date: Fri, 04 Jun 2004 11:58:13 +1000

The new text in Section 4.2 includes:

>    Since the protocol being defined in this set of documents is version
>    2.0, the 'protoversion' MUST be "2.0".  

Which renders several deployed implementations non-compliant and
is contradictory with section 5.1:

>    Server implementations MAY support a configurable "compatibility"
>    flag that enables compatibility with old versions.  When this flag is
>    on, the server SHOULD identify its protocol version as "1.99".
>    Clients using protocol 2.0 MUST be able to identify this as identical
>    to "2.0".  In this mode the server SHOULD NOT send the carriage
>    return character (ASCII 13) after the version identification string.

I suggest that the old text be restored or the validity of offering
a protocol version of 1.99 be mentioned in section 4.2.

I don't understand why new changes are being made to the drafts again
- I was under the impression that they were just about ready for
publication. Can someone more familiar with the process please explain
what stands in the way of this happening?

-d

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 04 Jun 2004 19:39:56 -0400

> what stands in the way of this happening?

The documents are currently under review by the IESG.

Any changes at this point should be primarily driven by comments from
the IESG, which can be found in the IETF draft tracker at:
	
	https://datatracker.ietf.org/public/pidtracker.cgi

Enter "secsh" in the WG acronym field) and hit "SEARCH".

Then pick a document, click on DETAIL to see its history.

In the Detail Info section, click on "IESG evaluation record" to see
IESG comments.

> a protocol version of 1.99 be mentioned in section 4.2.
Chris: can you clarify the intent of this change?  It appears to be
part of an attempt to respond to the following IESG comments:

    2. Section 3.3. This is clearly here to allow servers to interoperate with
    SSH version 1. However, there is no specification for SSHv1. The WG decided
    to not document SSHv1, even as an informational RFC. There are many SSHv1
    implementations, and at least one very large vendor has no intention of
    moving to SSHv2. A reference to some kind of SSHv1 specification is needed
    to provide context.

and
	
    4. Page 6, first paragraph. The SHOULD NOT conflicts with the MUST at the
    bottom of page 4. Suggestion: change the MUST at the bottom of page 4 to
    SHOULD.

(these may be a bit tricky to follow as sections were renumbered in
-17)

As Damien says, this is creating an internal inconsistancy within the document.

I suggest changing the "MUST" to something along the lines of:

    the 'protoversion' SHOULD be "2.0" unless the 
    compatibility flag described in section 5.1 is enabled.

Regarding a stable reference, 	

    For those interested, the SSH 1.x protocol.  The only known
   documentation of the 1.x protocol is contained in README files that
   are shipped along with the source code.

In section 5.0, I think we can generate a formal reference along the
lines of "The file named RFC within ftp://.../ssh-1.2.x.tar.gz"
given a suitably stable URL..

						- Bill

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 4 Jun 2004 17:42:03 -0700 (PDT)

Hi,

> (these may be a bit tricky to follow as sections were renumbered in

That's correct.  I've also placed it here:
  http://www.employees.org/~lonvick/secsh-wg/may19/transport-16-18.html

> As Damien says, this is creating an internal inconsistancy within the document.

Doh!  That wasn't my intent.  I was hoping to say that you MUST have "2.0"
for _this_ protocol but you MAY have "1.99" for backwards compatibility.

>     compatibility flag described in section 5.1 is enabled.

I'll work on that.

> given a suitably stable URL..

I'll get that into the Informational References section.

All:  I really do need feedback on any changes that are made.  These
changes need to appease the IESG reviewers _AND_ they need to be
technically correct.  The goal of the IESG in this is to ensure that we
produce a quality document that is very clear even to someone reading it
for the first time without any background in the subject.  This is really
required for a Standards Track RFC.  They, and ourselves, would also like
to get this done fairly quickly as they are creating a backlog - not only
for our documents but also for things relying upon SSH such as the NetConf
WG documents.

Keep those cards 'n letters comin' in.  :-)

Thanks,
Chris

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2004 12:41:34 -0500

> In the Detail Info section, click on "IESG evaluation record" to see

Bill, I found not much in the eval record for the transport draft, and
only a little more for the architecture and other core drafts.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2004 12:51:14 -0500

> only a little more for the architecture and other core drafts.

Never mind.  I've found it off the architecture draft, which does have
an eval record.

Nico
--