From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 14 21:03:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkA83-0001mI-LV for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 14 Nov 2006 21:03:55 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkA7w-0003gw-61 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 14 Nov 2006 21:03:55 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id BE90863B398; Wed, 15 Nov 2006 02:03:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by mail.netbsd.org (Postfix) with ESMTP id 07DD263B384 for ; Wed, 15 Nov 2006 02:03:21 +0000 (UTC) Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id kAF0MQoN017676; Tue, 14 Nov 2006 16:22:26 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id kAF0MQ1N017675; Tue, 14 Nov 2006 16:22:26 -0800 Date: Tue, 14 Nov 2006 16:22:26 -0800 Message-Id: <200611150022.kAF0MQ1N017675@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4716 on The Secure Shell (SSH) Public Key File Format From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ssh@netbsd.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: -14.8 (--------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 A new Request for Comments is now available in online RFC libraries. RFC 4716 Title: The Secure Shell (SSH) Public Key File Format Author: J. Galbraith, R. Thayer Status: Informational Date: November 2006 Mailbox: galb@vandyke.com, rodney@canola-jones.com Pages: 10 Characters: 18395 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-publickeyfile-13.txt URL: http://www.rfc-editor.org/rfc/rfc4716.txt This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations. In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community. This document is a product of the Secure Shell Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 09:28:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmA8G-0006rv-3A for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 09:28:24 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmA8C-0001va-Tt for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 09:28:24 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 1E33063B320; Mon, 20 Nov 2006 14:28:02 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 599B363B317 for ; Mon, 20 Nov 2006 14:28:00 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id 56CA369B43; Mon, 20 Nov 2006 23:30:45 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id DE2D669AFB; Mon, 20 Nov 2006 23:30:39 +1100 (EST) Received: by mail.mindrot.org (Postfix, from userid 1000) id 4B97D17E60A; Mon, 20 Nov 2006 23:30:39 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 4953A17E608; Mon, 20 Nov 2006 23:30:39 +1100 (EST) Date: Mon, 20 Nov 2006 23:30:39 +1100 (EST) From: Damien Miller To: internet-drafts@ietf.org cc: ietf-ssh@netbsd.org Subject: Publish ID draft-openssh-secsh-compression-delayed-00.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1164930027-1164025648=:14159" Content-ID: Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1164930027-1164025648=:14159 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, Please publish the attached I-D: draft-openssh-secsh-compression-delayed-00.txt Thanks, Damien Miller --0-1164930027-1164025648=:14159 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=draft-openssh-secsh-compression-delayed-00.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=draft-openssh-secsh-compression-delayed-00.txt DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgTS4gRnJpZWRsDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBELiBNaWxsZXINCkV4cGlyZXM6IE1heSAyNCwgMjAwNyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3BlblNT SA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5vdmVtYmVyIDIwLCAyMDA2DQoNCg0KICAgICAgICAg IERlbGF5ZWQgY29tcHJlc3Npb24gdGhlIFNTSCBUcmFuc3BvcnQgTGF5ZXIg UHJvdG9jb2wNCiAgICAgICAgICAgICBkcmFmdC1vcGVuc3NoLXNlY3NoLWNv bXByZXNzaW9uLWRlbGF5ZWQtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1l bW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBl YWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxl IHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNo ZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2Vk LCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2Fy ZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rp b24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQog ICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtp bmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAg IFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rvcmll cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gTWF5IDI0LCAyMDA3Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoN CiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYp Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gZGVzY3JpYmVzIGEgbmV3 IGNvbXByZXNzaW9uIG1ldGhvZCBmb3IgdGhlIFNTSCBwcm90b2NvbC4NCiAg IFRoaXMgbmV3IG1ldGhvZCB1c2VzIHRoZSBzYW1lIHpsaWIgY29tcHJlc3Np b24gYWxnb3JpdGhtIGFzIHRoZQ0KICAgZXhpc3RpbmcgbWV0aG9kIGRlc2Ny aWJlZCBpbiB0aGUgY29yZSBTU0ggZHJhZnRzIGJ1dCBkZWxheXMgdGhlIHN0 YXJ0DQogICBvZiBjb21wcmVzc2lvbiB1bnRpbCBhZnRlciB1c2VyIGF1dGhl bnRpY2F0aW9uIGhhcyBjb21wbGV0ZWQuICBUaGlzDQogICBlbGltaW5hdGVz IHRoZSByaXNrIG9mIGEgYnVnIGluIGNvbXByZXNzaW9uIGxpYnJhcmllcyBy ZXN1bHRpbmcgaW4gYQ0KICAgcHJlLWF1dGhlbnRpY2F0aW9uIGNvbXByb21p c2Ugb2YgYW4gU1NIIHNlcnZlci4NCg0KDQoNCg0KDQpGcmllZGwgJiBNaWxs ZXIgICAgICAgICAgIEV4cGlyZXMgTWF5IDI0LCAyMDA3ICAgICAgICAgICAg ICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgU1NIIHpsaWJA b3BlbnNzaC5jb20gY29tcHJlc3Npb24gbWV0aG9kICAgTm92ZW1iZXIgMjAw Ng0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBSZXF1aXJlbWVu dHMgbm90YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMw0KICAgMi4gIE92ZXJ2aWV3ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQogICAz LiAgRGVsYXllZCBDb21wcmVzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMNCiAgIDQuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMw0KICAgNS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICBBdXRo b3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDUNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gNg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K RnJpZWRsICYgTWlsbGVyICAgICAgICAgICBFeHBpcmVzIE1heSAyNCwgMjAw NyAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgIFNTSCB6bGliQG9wZW5zc2guY29tIGNvbXByZXNzaW9uIG1ldGhvZCAg IE5vdmVtYmVyIDIwMDYNCg0KDQoxLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9u DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0 ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KDQoyLiAgT3ZlcnZp ZXcNCg0KICAgU1NIIFtSRkM0MjUxXSBpcyBhIHBvcHVsYXIgcHJvdG9jb2wg Zm9yIHNlY3VyZSByZW1vdGUgbG9naW4gYW5kIGRhdGENCiAgIHRyYW5zZmVy IG9uIHRoZSBJbnRlcm5ldC4gIEluY2x1ZGVkIGluIHRoZSBwcm90b2NvbCBp cyB0aGUgYWJpbGl0eSB0bw0KICAgY29tcHJlc3MgZGF0YSBiZXR3ZWVuIHRo ZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIsIG9mZmVyaW5nIHRocm91Z2hwdXQN CiAgIGltcHJvdmVtZW50cyBhbmQgdHJhZmZpYyBzYXZpbmdzIHdoZW4gdXNl ZCBvbiBjb21wcmVzc2libGUgZGF0YS4NCg0KICAgVGhlICJ6bGliIiBjb21w cmVzc2lvbiBpbiBtZXRob2QgZGVmaW5lZCBpbiBbUkZDNDI1M10gZm9yIHRo ZSBTU0gNCiAgIHByb3RvY29sIHVzZXMgWkxJQiAoTFo3NykgY29tcHJlc3Np b24gKGFzIGRlc2NyaWJlZCBpbiBbUkZDMTk1MF0gYW5kDQogICBbUkZDMTk1 MV0pLiAgVGhpcyBtZXRob2QgYWN0aXZhdGVzIGNvbXByZXNzaW9uIGFmdGVy IHRoZSBjb21wbGV0aW9uDQogICBvZiB0aGUga2V5IGV4Y2hhbmdlIGFsZ29y aXRobSwgdXBvbiB0aGUgcmVjZWlwdCBvZiB0aGUNCiAgIFNTSF9NU0dfTkVX S0VZUyBtZXNzYWdlLiAgVGhpcyBzdGVwIG9jY3VycyBiZWZvcmUgdXNlciBh dXRoZW50aWNhdGlvbg0KICAgW1JGQzQyNTJdIGNvbXBsZXRlcywgc28gYSBi dWcgaW4gdGhlIHVuZGVybHlpbmcgY29tcHJlc3Npb24gY29kZQ0KICAgY291 bGQgYmUgZXhwb3NlZCB0byB1bmF1dGhlbnRpY2F0ZWQgdXNlcnMuDQoNCiAg IFRoaXMgbmV3IGNvbXByZXNzaW9uIG1ldGhvZCAiemxpYkBvcGVuc3NoLmNv bSIgYWRkcmVzc2VzIHRoaXMgcmlzayBieQ0KICAgZGVsYXlpbmcgdGhlIHN0 YXJ0IG9mIGNvbXByZXNzaW9uIHVudGlsIHRoZSBjb21wbGV0aW9uIG9mIHRo ZSB1c2VyDQogICBhdXRoZW50aWNhdGlvbiBleGNoYW5nZS4NCg0KDQozLiAg RGVsYXllZCBDb21wcmVzc2lvbg0KDQogICBUaGUgInpsaWJAb3BlbnNzaC5j b20iIG1ldGhvZCBvcGVyYXRlcyBpZGVudGljYWxseSB0byB0aGUgInpsaWIi DQogICBtZXRob2QgZGVzY3JpYmVkIGluIFtSRkM0MjUyXSBleGNlcHQgdGhh dCBwYWNrZXQgY29tcHJlc3Npb24gZG9lcyBub3QNCiAgIHN0YXJ0IHVudGls IHRoZSBzZXJ2ZXIgc2VuZHMgYSBTU0hfTVNHX1VTRVJBVVRIX1NVQ0NFU1Mg cGFja2V0LA0KICAgcmVwbGFjaW5nIHRoZSAiemxpYiIgbWV0aG9kJ3Mgc3Rh cnQgb2YgY29tcHJlc3Npb24gd2hlbiB0aGUgc2VydmVyDQogICBzZW5kcyBT U0hfTVNHX05FV0tFWVMuDQoNCiAgIFNwZWNpZmljYWxseSwgdGhpcyBtZWFu cyB0aGF0IGEgc2VydmVyIHNlbGVjdGluZyB0aGlzIG1ldGhvZCBNVVNUDQog ICBjb21wcmVzcyB0aGUgZmlyc3QgcGFja2V0IGFmdGVyIFNTSF9NU0dfVVNF UkFVVEhfU1VDQ0VTUyBhbmQgYWxsDQogICBzdWJzZXF1ZW50IHBhY2tldHMu ICBUaGUgY2xpZW50IE1VU1QgY29tcHJlc3MgYWxsIHBhY2tldHMgaXQgc2Vu ZHMNCiAgIGFmdGVyIHRoZSB0aW1lIHRoYXQgaXQgcmVjZWl2ZXMgU1NIX01T R19VU0VSQVVUSF9TVUNDRVNTLg0KDQogICBBbiBpbXBsZW1lbnRhdGlvbiBv ZiB0aGlzIG1ldGhvZCBzaG91bGQgYmUgY2FyZWZ1bCB0byBlbnN1cmUgdGhh dA0KICAgY29tcHJlc3Npb24gaXMgZW5hYmxlZCBieSBzdWJzZXF1ZW50IHJl LWtleWluZyBleGNoYW5nZXMgYWZ0ZXINCiAgIGF1dGhlbnRpY2F0aW9uLg0K DQoNCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBEZWxheWlu ZyBjb21wcmVzc2lvbiB1bnRpbCBhZnRlciBhdXRoZW50aWNhdGlvbiBtYXkg cmV2ZWFsIHNsaWdodGx5DQoNCg0KDQpGcmllZGwgJiBNaWxsZXIgICAgICAg ICAgIEV4cGlyZXMgTWF5IDI0LCAyMDA3ICAgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgU1NIIHpsaWJAb3BlbnNzaC5j b20gY29tcHJlc3Npb24gbWV0aG9kICAgTm92ZW1iZXIgMjAwNg0KDQoNCiAg IG1vcmUgZXhhY3QgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGxlbmd0aCBvZiBh dXRoZW50aWNhdGlvbiBkYXRhLiAgSXQNCiAgIGlzIGRvdWJ0ZnVsIHRoYXQg dGhpcyB3b3VsZCBhc3Npc3QgYW4gYXR0YWNrZXI7IHRoZSBjb21wcmVzc2Vk IGxlbmd0aA0KICAgb2YgYW4gYXV0aGVudGljYXRpb24gc2VjcmV0IGlzIG9m IHNpbWlsYXIgaW50ZXJlc3QgdG8gYW4gYXR0YWNrZXIgYXMNCiAgIGl0cyB1 bmNvbXByZXNzZWQgbGVuZ3RoLiAgSW1wbGVtZW50YXRpb25zIHNob3VsZCBi ZSB0YWtpbmcgc3RlcHMgdG8NCiAgIG9ic2N1cmUgdGhlIGV4YWN0IGxlbmd0 aCBvZiBhdXRoZW50aWNhdGlvbiBzZWNyZXRzIGFueXdheS4NCg0KICAgVGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFtSRkM0MjUxXSBhbHNvIGFw cGx5IHRvIHRoaXMNCiAgIGNvbXByZXNzaW9uIG1ldGhvZC4NCg0KNS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMxOTUwXSAgRGV1dHNjaCwg TC4gYW5kIEotTC4gR2FpbGx5LCAiWkxJQiBDb21wcmVzc2VkIERhdGEgRm9y bWF0DQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24gdmVyc2lvbiAzLjMi LCBSRkMgMTk1MCwgTWF5IDE5OTYuDQoNCiAgIFtSRkMxOTUxXSAgRGV1dHNj aCwgUC4sICJERUZMQVRFIENvbXByZXNzZWQgRGF0YSBGb3JtYXQgU3BlY2lm aWNhdGlvbg0KICAgICAgICAgICAgICB2ZXJzaW9uIDEuMyIsIFJGQyAxOTUx LCBNYXkgMTk5Ni4NCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAg ICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwg TWFyY2ggMTk5Ny4NCg0KICAgW1JGQzQyNTFdICBZbG9uZW4sIFQuIGFuZCBD LiBMb252aWNrLCAiVGhlIFNlY3VyZSBTaGVsbCAoU1NIKQ0KICAgICAgICAg ICAgICBQcm90b2NvbCBBcmNoaXRlY3R1cmUiLCBSRkMgNDI1MSwgSmFudWFy eSAyMDA2Lg0KDQogICBbUkZDNDI1Ml0gIFlsb25lbiwgVC4gYW5kIEMuIExv bnZpY2ssICJUaGUgU2VjdXJlIFNoZWxsIChTU0gpDQogICAgICAgICAgICAg IEF1dGhlbnRpY2F0aW9uIFByb3RvY29sIiwgUkZDIDQyNTIsIEphbnVhcnkg MjAwNi4NCg0KICAgW1JGQzQyNTNdICBZbG9uZW4sIFQuIGFuZCBDLiBMb252 aWNrLCAiVGhlIFNlY3VyZSBTaGVsbCAoU1NIKQ0KICAgICAgICAgICAgICBU cmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wiLCBSRkMgNDI1MywgSmFudWFyeSAy MDA2Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCkZyaWVkbCAmIE1pbGxlciAgICAgICAgICAgRXhwaXJlcyBNYXkg MjQsIDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICBTU0ggemxpYkBvcGVuc3NoLmNvbSBjb21wcmVzc2lvbiBt ZXRob2QgICBOb3ZlbWJlciAyMDA2DQoNCg0KQXV0aG9ycycgQWRkcmVzc2Vz DQoNCiAgIE1hcmt1cyBGcmllZGwNCiAgIE9wZW5TU0gNCg0KICAgRW1haWw6 IG1hcmt1c0BvcGVuc3NoLmNvbQ0KDQoNCiAgIERhbWllbiBNaWxsZXINCiAg IE9wZW5TU0gNCg0KICAgRW1haWw6IGRqbUBvcGVuc3NoLmNvbQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRnJpZWRsICYgTWlsbGVyICAg ICAgICAgICBFeHBpcmVzIE1heSAyNCwgMjAwNyAgICAgICAgICAgICAgICAg IFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgIFNTSCB6bGliQG9wZW5z c2guY29tIGNvbXByZXNzaW9uIG1ldGhvZCAgIE5vdmVtYmVyIDIwMDYNCg0K DQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJ RVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkg b3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8N CiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0 aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQg b3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNo IHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsg bm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFu eSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGgg cmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAg IGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2Yg SVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQg YW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRl IGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBt YWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9u IGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBi eSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNh dGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4N Cg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9w cmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kg dGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0 YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRo ZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFp bWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBh bg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUg T1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9O U09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBU SEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xB SU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElO Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQg VEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5P VCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJS QU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBB UlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoN CiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYp LiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRz LCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1Ag NzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUg YXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3ds ZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5j dGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5l dCBTb2NpZXR5Lg0KDQoNCg0KDQpGcmllZGwgJiBNaWxsZXIgICAgICAgICAg IEV4cGlyZXMgTWF5IDI0LCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2Ug Nl0NCgwNCg== --0-1164930027-1164025648=:14159-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 11:15:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBoJ-0001xo-5I for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 11:15:55 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBoH-0003rZ-OG for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 11:15:55 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 5726A63B32A; Mon, 20 Nov 2006 16:15:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 16E0863B325 for ; Mon, 20 Nov 2006 16:15:46 +0000 (UTC) Received: from [192.168.0.3] (account galb HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 933139; Mon, 20 Nov 2006 08:15:44 -0700 Message-ID: <4561C69C.3060103@vandyke.com> Date: Mon, 20 Nov 2006 08:15:40 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Damien Miller CC: internet-drafts@ietf.org, ietf-ssh@netbsd.org Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Damien Miller wrote: > Hi, > > Please publish the attached I-D: draft-openssh-secsh-compression-delayed-00.txt Thanks for publishing this; just FYI: I believe we have an inter-operable implementation of this. > The "zlib" compression in method defined in [RFC4253] for the SSH > protocol uses ZLIB (LZ77) compression (as described in [RFC1950] and > [RFC1951]). This method activates compression after the completion > of the key exchange algorithm, upon the receipt of the > SSH_MSG_NEWKEYS message. This step occurs before user authentication > [RFC4252] completes, so a bug in the underlying compression code > could be exposed to unauthenticated users. > > This new compression method "zlib@openssh.com" addresses this risk by > delaying the start of compression until the completion of the user > authentication exchange. An additional benefit of this is that it prevents sensitive information such as the username and password from becoming part of the internal zlib state where it is hard to scrub it from memory. > 3. Delayed Compression > > The "zlib@openssh.com" method operates identically to the "zlib" > method described in [RFC4252] except that packet compression does not I believe you probably meant to reference RFC4253 (transport) here? > start until the server sends a SSH_MSG_USERAUTH_SUCCESS packet, > replacing the "zlib" method's start of compression when the server > sends SSH_MSG_NEWKEYS. > > Specifically, this means that a server selecting this method MUST > compress the first packet after SSH_MSG_USERAUTH_SUCCESS and all > subsequent packets. The client MUST compress all packets it sends > after the time that it receives SSH_MSG_USERAUTH_SUCCESS. Isn't this problematic on the client side? The server doesn't know when the client will receive the SSH_MSG_USERAUTH_SUCCESS. In fact, I RFC4352 allows the client to send multiple auth requests with out waiting for a response. The server is suppose to ignore any auth requests after success: > The client MAY send several authentication requests without waiting > for responses from previous requests. The server MUST process each > request completely and acknowledge any failed requests with a > SSH_MSG_USERAUTH_FAILURE message before processing the next request. > > A request that requires further messages to be exchanged will be > aborted by a subsequent request. A client MUST NOT send a subsequent > request if it has not received a response from the server for a > previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be > sent for an aborted method. > > SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When > SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication > requests received after that SHOULD be silently ignored. In this case (or possibly in the case of DEBUG, IGNORE, or even a KEXINIT packet) the server might receive uncompressed packets after it sends the SSH_MSG_USERAUTH_SUCCESS-- the server really has no way of determining at what point the packet stream became compressed. Of course in most implementations, it is okay since clients tend to send one auth method at a time and wait for the response. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 11:23:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBvo-0004Lm-O8 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 11:23:40 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBvm-0004J9-B0 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 11:23:40 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id A050C63B329; Mon, 20 Nov 2006 16:23:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ixion.tartarus.org (ixion.tartarus.org [82.211.108.121]) by mail.netbsd.org (Postfix) with ESMTP id 921C763B32D for ; Mon, 20 Nov 2006 16:23:33 +0000 (UTC) Received: from simon by ixion.tartarus.org with local (Exim 3.36 #1 (Debian)) id 1GmAbC-0001ob-00; Mon, 20 Nov 2006 14:58:18 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 20 Nov 2006 14:58:18 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Damien Miller wrote: > The "zlib@openssh.com" method operates identically to the "zlib" > method described in [RFC4252] except that packet compression does not > start until the server sends a SSH_MSG_USERAUTH_SUCCESS packet, > replacing the "zlib" method's start of compression when the server > sends SSH_MSG_NEWKEYS. > > Specifically, this means that a server selecting this method MUST > compress the first packet after SSH_MSG_USERAUTH_SUCCESS and all > subsequent packets. The client MUST compress all packets it sends > after the time that it receives SSH_MSG_USERAUTH_SUCCESS. (I've already said this to Damien, but I'll say it here as well now this is published.) I believe this specification includes an inherent race condition, causing the server to be unable to unambiguously determine whether a given packet from the client is compressed or not. The last userauth-layer packet sent by the client (say, SSH_MSG_USERAUTH_REQUEST) is clearly uncompressed, because the server hasn't sent SSH_MSG_USERAUTH_SUCCESS in response to it yet. And the first connection-layer packet is clearly compressed, because the client wouldn't have sent it except in response _to_ SSH_MSG_USERAUTH_SUCCESS. But what about transport-layer packets in between? If the client sends SSH_MSG_IGNORE, or initiates a rekey, in between the last userauth-layer packet and the first connection-layer packet, then the server might easily be unable to tell whether that client packet was sent before or after the client received SSH_MSG_USERAUTH_SUCCESS. The packet contains no flag to indicate whether it's compressed; you can't go by the packet type code because that's part of the potentially compressed payload; as far as I can see there is no reliable way to resolve this race condition. There should be a packet sent from the client which explicitly indicates that subsequent packets will be compressed, as there is in the normal KEX procedure (SSH_MSG_NEWKEYS is sent in _both_ directions). The server-to-client side is unambiguous, of course, because SSH_MSG_USERAUTH_SUCCESS itself doubles as that packet. As far as I can see, the only _safe_ way for a client to implement this compression method as currently specified is to note it being offered in the initial kex, but not to accept that offer, and then to initiate a rekey after authentication in which we enable it. -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 13:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmDX0-0003wi-Gj for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 13:06:10 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmDWw-0005Dj-K6 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 13:06:10 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 36A5363B258; Mon, 20 Nov 2006 18:05:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id BB0E663B192 for ; Mon, 20 Nov 2006 18:05:45 +0000 (UTC) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAKI5iXn024752 for ; Mon, 20 Nov 2006 11:05:45 -0700 (MST) Received: from localhost.East.Sun.COM (dhcp-unyc10-65-230.East.Sun.COM [129.154.65.230]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAKI5hNg025279 for ; Mon, 20 Nov 2006 13:05:44 -0500 (EST) Received: from localhost.East.Sun.COM (localhost [127.0.0.1]) by localhost.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kAKI50BI005001; Mon, 20 Nov 2006 18:05:00 GMT Received: (from sommerfeld@localhost) by localhost.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kAKI4xqw005000; Mon, 20 Nov 2006 13:04:59 -0500 (EST) X-Authentication-Warning: localhost.East.Sun.COM: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: Damien Miller , internet-drafts@ietf.org, ietf-ssh@NetBSD.org In-Reply-To: <4561C69C.3060103@vandyke.com> References: <4561C69C.3060103@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 20 Nov 2006 13:04:58 -0500 Message-Id: <1164045898.877.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 On Mon, 2006-11-20 at 08:15 -0700, Joseph Galbraith wrote: > Isn't this problematic on the client side? The server doesn't > know when the client will receive the SSH_MSG_USERAUTH_SUCCESS. Indeed. Seems to me like you'd need a client message saying "compression starts after this message" to avoid this ambiguity. - Bill From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 19:44:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJkQ-0008Ci-70 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 19:44:26 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJkN-0007qW-9d for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 19:44:26 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 8833563B241; Tue, 21 Nov 2006 00:44:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from server10.webplus24.de (server10.webplus24.de [82.210.20.10]) by mail.netbsd.org (Postfix) with ESMTP id 691CF63B382 for ; Tue, 21 Nov 2006 00:44:06 +0000 (UTC) Received: from web144 by server10.webplus24.de with local (Exim 4.50) id 1GhrRu-0001qZ-Qe for ietf-ssh@netbsd.org; Wed, 08 Nov 2006 18:42:54 +0100 To: ietf-ssh@netbsd.org Subject: From Deacon James Mahathia From: Elizabeth & Deacon James Mahathia Reply-To: DeaconJames_Mahathia@tangana.com MIME-Version: 1.0 Content-Type: text/plain Message-Id: Date: Wed, 08 Nov 2006 18:42:54 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Dear In Christ , The time has come for Christians to worship God in spirit and in truth according to the book of John chapter 4:vs23-24.``But the hour cometh and now is when the true worshipers shall worship the Father in spirit and in truth: for the Father seeketh such to worship him . God is a spirit, and they that worship him must worship him in spirit and in truth. Based on this scripture, it became obvious that I should do=20 the right thing if I must enter into the kingdom of God. I am , Deacon James Mahathia the legal adviser to late Mr. Mike & Carol Hall, a God fearing and dedicated couple. They were very wealthy but=20 had no child. They travelled to Patong-Thailand for Christmas holiday=20 but met death on the 26th of December 2004 during the Tsunami disaster(http://news.bbc.co.uk/1/hi/england/bristol/4153821.stm As their legal adviser, before their death, the husband Mr. Mike Hall instructed me to write his WILL, because they had no child, he=20 dedicated their wealth to God. They had a lot of landed properties=20 houses Stocks/bonds, etc. According to their instruction. According to the WILL, their assets should be given out to a ministry for the work of God. As their legal adviser, all the documents for the fund that are deposited with the Vault company are in my care. As a=20 born again Christian , I have been reading my bible and I have to do=20 what is lawful and right in the sight of God by giving out the fund to th= e chosen ministry for the purpose of God's work as instructed by the owners before there death. After my fasting and prayers Today, I asked God to make his choice and direct me to an honest Christian or the chosen ministry that deserves this fund by his Grace. I then came=20 across your address on the Internet.I appeal to you to use the fund=20 wisely for things that will glorify the name of God. I have just notified= the Vault Company where they deposited the=20 consignments that contained the=20 fund, that I am moving the consignment abroad, and the Vault company is awaiting my instruction to move the Trunks out of Turkey. Also, could you get back to me having visiting the above website to enable us discuss in a more clarifying manner to the best of your understanding. I must say that I'm very uncomfortable sending this message to you without knowing truly if you would misconstrue the importance and decides to go public. In this regards, I will not hold back to say that the essence of this message is strictly for Charity. May God bless you as you make up your mind to work for God. Thanks. Deacon James Mahathia Tel:+447040117932 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 19:44:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJkg-0008FS-EQ for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 19:44:42 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJkd-0007v8-Hf for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 19:44:42 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id DA42863B37C; Tue, 21 Nov 2006 00:44:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by mail.netbsd.org (Postfix) with ESMTP id 2D87A63B1EF for ; Tue, 21 Nov 2006 00:44:37 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kAKMsKBW006362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Nov 2006 17:54:22 -0500 (EST) Date: Mon, 20 Nov 2006 17:53:53 -0500 From: Jeffrey Hutzelman To: Simon Tatham , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt Message-ID: <786826D48F46245D2B5CEA84@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01Ri3MYLCVQdSSeETheav8z92fA4vNYUWzovrFfK0=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 On Monday, November 20, 2006 02:58:18 PM +0000 Simon Tatham wrote: > As far as I can see, the only _safe_ way for a client to implement > this compression method as currently specified is to note it being > offered in the initial kex, but not to accept that offer, and then > to initiate a rekey after authentication in which we enable it. ... at which point, compression would start after SSH_MSG_NEWKEYS :-) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 20:22:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmKKn-00031Y-R4 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 20:22:01 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmKKk-0004wm-UL for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 20:22:01 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 856EB63B1E1; Tue, 21 Nov 2006 01:21:53 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 8793563B192 for ; Tue, 21 Nov 2006 01:21:52 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id A965469B82; Tue, 21 Nov 2006 12:21:51 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 5278569B4B; Tue, 21 Nov 2006 12:21:49 +1100 (EST) Received: by mail.mindrot.org (Postfix, from userid 1000) id B5F4E17E60A; Tue, 21 Nov 2006 12:21:48 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id B46CC17E608; Tue, 21 Nov 2006 12:21:48 +1100 (EST) Date: Tue, 21 Nov 2006 12:21:48 +1100 (EST) From: Damien Miller To: Bill Sommerfeld cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt In-Reply-To: <1164045898.877.69.camel@localhost> Message-ID: References: <4561C69C.3060103@vandyke.com> <1164045898.877.69.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 [removing internet-drafts@ from the Cc] On Mon, 20 Nov 2006, Bill Sommerfeld wrote: > On Mon, 2006-11-20 at 08:15 -0700, Joseph Galbraith wrote: > > Isn't this problematic on the client side? The server doesn't > > know when the client will receive the SSH_MSG_USERAUTH_SUCCESS. > > Indeed. Seems to me like you'd need a client message saying > "compression starts after this message" to avoid this ambiguity. That is a good idea. As other have observed, OpenSSH doesn't suffer from the race because it doesn't send other packets after authentication. So we could define a global message with no "payload": SSH_MSG_CLIENT_AUTHDONE 62 The client would send this message upon receipt of the SSH_MSG_USERAUTH_SUCCESS. If the client has selected the delayed compression mode, it will be the last uncompressed message it sends. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Nov 20 22:28:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmMJf-0008T3-65 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 22:28:59 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmMJb-0004G3-90 for secsh-tyoxbijeg7-archive@lists.ietf.org; Mon, 20 Nov 2006 22:28:59 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id E05E163B389; Tue, 21 Nov 2006 03:28:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mail.netbsd.org (Postfix) with ESMTP id AD8C263B384 for ; Tue, 21 Nov 2006 03:28:35 +0000 (UTC) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kAL3SZpP022363 for ; Mon, 20 Nov 2006 19:28:35 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kAL3SYJO026178 for ; Mon, 20 Nov 2006 20:28:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kAL3SX1F007697; Mon, 20 Nov 2006 21:28:33 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kAL3SWsY007696; Mon, 20 Nov 2006 21:28:32 -0600 (CST) Date: Mon, 20 Nov 2006 21:28:32 -0600 From: Nicolas Williams To: Damien Miller Cc: Bill Sommerfeld , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt Message-ID: <20061121032832.GT5938@binky.Central.Sun.COM> References: <4561C69C.3060103@vandyke.com> <1164045898.877.69.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On Tue, Nov 21, 2006 at 12:21:48PM +1100, Damien Miller wrote: > [removing internet-drafts@ from the Cc] > > On Mon, 20 Nov 2006, Bill Sommerfeld wrote: > > > On Mon, 2006-11-20 at 08:15 -0700, Joseph Galbraith wrote: > > > Isn't this problematic on the client side? The server doesn't > > > know when the client will receive the SSH_MSG_USERAUTH_SUCCESS. > > > > Indeed. Seems to me like you'd need a client message saying > > "compression starts after this message" to avoid this ambiguity. > > That is a good idea. As other have observed, OpenSSH doesn't suffer from > the race because it doesn't send other packets after authentication. > > So we could define a global message with no "payload": > > SSH_MSG_CLIENT_AUTHDONE 62 SSH_MSG_NEW_COMPRESSION, make its payload the name of the compression algorithm. Or re-use KEX, see below. > The client would send this message upon receipt of the SSH_MSG_USERAUTH_SUCCESS. Or whenever it wants, but NOT before then (since the whole point is not to have compression in use prior to dropping privileges needed to perform authentication on the server side). > If the client has selected the delayed compression mode, it will be the > last uncompressed message it sends. The nice thing about using a KEX for negotiating a new compression algorithm is that both peers are in control -- the server can continue to not offer compression until authentication is completed, for example. With SSH_MSG_NEW_COMPRESSION the client can't know whether the server is ready for it. And the whole we-need-this-so-we-can-do-compression- after-dropping-privs thing smacks me as rather implementation specific. KEX doesn't have that problem. What's not nice about using KEX to negotiate a new compression algorithm is that KEX is not cheap. If there was a no-op key exchange algorithm for use in re-keying whose purpose was to allow re-negotiation of things other than session keys (and could not be used for initial KEX, but could be advertised in initial KEX) then we could just use KEXINIT/KEX*/NEWKEYS to negotiate compression and all would be fine. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 21 00:12:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmNvg-0006bu-5l for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 00:12:20 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmNvZ-0002xs-6Z for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 00:12:20 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 61C9963B1DC; Tue, 21 Nov 2006 05:12:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.netbsd.org (Postfix) with ESMTP id 64D9163B1C7 for ; Tue, 21 Nov 2006 05:12:06 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 1002) id 1345C69B73; Tue, 21 Nov 2006 16:12:05 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.4 Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Free CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTP id 71B0769B6B; Tue, 21 Nov 2006 16:12:02 +1100 (EST) Received: by mail.mindrot.org (Postfix, from userid 1000) id C667D17E60A; Tue, 21 Nov 2006 16:12:01 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id C254817E608; Tue, 21 Nov 2006 16:12:01 +1100 (EST) Date: Tue, 21 Nov 2006 16:12:01 +1100 (EST) From: Damien Miller To: Nicolas Williams cc: Bill Sommerfeld , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt In-Reply-To: <20061121032832.GT5938@binky.Central.Sun.COM> Message-ID: References: <4561C69C.3060103@vandyke.com> <1164045898.877.69.camel@localhost> <20061121032832.GT5938@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Mon, 20 Nov 2006, Nicolas Williams wrote: > With SSH_MSG_NEW_COMPRESSION the client can't know whether the server is > ready for it. And the whole we-need-this-so-we-can-do-compression- > after-dropping-privs thing smacks me as rather implementation specific. Which is why I suggested a "client authentication complete" and not a "I'm starting compression" message. The message will only have meaning to a server that is using a delayed compression method, and the server can respond appropriately if it is sent at an inappropriate time, such as before it has sent a SSH_MSG_USERAUTH_SUCCESS. > KEX doesn't have that problem. > > What's not nice about using KEX to negotiate a new compression algorithm > is that KEX is not cheap. If there was a no-op key exchange algorithm > for use in re-keying whose purpose was to allow re-negotiation of things > other than session keys (and could not be used for initial KEX, but > could be advertised in initial KEX) then we could just use > KEXINIT/KEX*/NEWKEYS to negotiate compression and all would be fine. Well, the only things that can be safely renegotiated in KEX are compression and languages - I don't think it would be safe to renegotiate MACs/ciphers whilst retaining the same keys. I don't see much practicality in renegotiating languages, so you would effectively be defining a whole new KEX exchange just to negotiate the compression method. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 21 09:39:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmWmQ-0007Br-IA for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 09:39:22 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmWmN-00014d-NM for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 09:39:22 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id 060BE63B3D7; Tue, 21 Nov 2006 14:39:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 3839763B3D5 for ; Tue, 21 Nov 2006 14:39:09 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GmVpr-0006nc-00; Tue, 21 Nov 2006 13:38:51 +0000 From: Ben Harris To: djm@mindrot.org Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt In-Reply-To: References: <1164045898.877.69.camel@localhost> <1164045898.877.69.camel@localhost> Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Tue, 21 Nov 2006 13:38:51 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 In article you write: >So we could define a global message with no "payload": > >SSH_MSG_CLIENT_AUTHDONE 62 > >The client would send this message upon receipt of the SSH_MSG_USERAUTH_SUCCESS. >If the client has selected the delayed compression mode, it will be the >last uncompressed message it sends. You probably don't want to use 62, since that's in the range reserved for the current userauth method. Somewhere in 54-59 would be more appropriate (and would require a Standards Action to get it allocated). It seems to me, though, that allocating a whole new message number is overkill here. If you're happy to overload existing messages, you could just say that the last uncompressed packets are the SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT for "ssh-connection". -- Ben Harris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Nov 21 10:17:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXNI-0004Aa-DP for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 10:17:28 -0500 Received: from mail.netbsd.org ([2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXNE-0004y7-B2 for secsh-tyoxbijeg7-archive@lists.ietf.org; Tue, 21 Nov 2006 10:17:28 -0500 Received: by mail.netbsd.org (Postfix, from userid 0) id AE84C63B33E; Tue, 21 Nov 2006 15:17:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id E12B263B15E for ; Tue, 21 Nov 2006 15:17:18 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1GmXN7-000705-00; Tue, 21 Nov 2006 15:17:17 +0000 From: Ben Harris To: bjh21@bjh21.me.uk Subject: Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt In-Reply-To: References: Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Tue, 21 Nov 2006 15:17:17 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 In article you write: >In article you write: >>So we could define a global message with no "payload": >> >>SSH_MSG_CLIENT_AUTHDONE 62 >> >>The client would send this message upon receipt of the SSH_MSG_USERAUTH_SUCCESS. >>If the client has selected the delayed compression mode, it will be the >>last uncompressed message it sends. > >You probably don't want to use 62, since that's in the range reserved >for the current userauth method. Somewhere in 54-59 would be more >appropriate (and would require a Standards Action to get it allocated). > >It seems to me, though, that allocating a whole new message number is >overkill here. If you're happy to overload existing messages, you could >just say that the last uncompressed packets are the >SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT for "ssh-connection". Simon's just pointed out that I'm being an idiot and this isn't how ssh-connection starts. Sorry about that. -- Ben Harris