From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 11 20:25:09 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FBA3A6898 for ; Wed, 11 Aug 2010 20:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqjYB1MaHuEZ for ; Wed, 11 Aug 2010 20:25:09 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id B6FA63A687F for ; Wed, 11 Aug 2010 20:25:05 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id D3FAA70725 for ; Thu, 12 Aug 2010 03:25:41 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id D6B8F63B101; Thu, 12 Aug 2010 03:25:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from shannon.crazycode.ca (shannon.crazycode.ca [173.203.208.70]) by mail.netbsd.org (Postfix) with ESMTP id 6116D63B100 for ; Thu, 12 Aug 2010 03:25:23 +0000 (UTC) Received: from [131.181.19.192] (unknown [131.181.19.192]) (Authenticated sender: dstebila@crazycode.ca) by shannon.crazycode.ca (Postfix) with ESMTPSA id 83AC998112 for ; Wed, 11 Aug 2010 22:09:33 -0400 (EDT) From: Douglas Stebila Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: New draft of X.509v3 Certificates for Secure Shell Authentication Date: Thu, 12 Aug 2010 12:07:42 +1000 Message-Id: To: ietf-ssh@netbsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list We have just posted a new version of the draft for using X.509v3 = certificates in SSH. The main change in this new version is the = addition of x509v3-rsa2048-sha256 public key format; see section 3.3. =20= The motivation for adding this public key format is to provide an RSA = solution that is compatible with the NIST draft SP800-131 = recommendations on key lengths, which deprecate RSA<2048 and SHA-1 for = signature generation after 2010. While there is value in considering revising the plain RSA public key = format as well to support SHA-256, we have refrained from doing so in = this document so it stays focused on X.509v3 certificates only. Feedback is welcome. Douglas > Filename: draft-igoe-secsh-x509v3 > Revision: 05 > Title: X.509v3 Certificates for Secure Shell = Authentication > Creation_date: 2010-08-12 > WG ID: Independent Submission > Number_of_pages: 19 >=20 > Abstract: > X.509 public key certificates use a signature by a trusted > certification authority to bind a given public key to a given digital > identity. This document specifies how to use X.509 version 3 public > key certificates in public key algorithms in the Secure Shell > protocol. >=20 > http://www.ietf.org/id/draft-igoe-secsh-x509v3-05.txt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 12 23:02:33 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0D13A68DD for ; Thu, 12 Aug 2010 23:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJBDRF0W4Di8 for ; Thu, 12 Aug 2010 23:02:32 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id BCA563A6892 for ; Thu, 12 Aug 2010 23:02:28 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id EE8B2709CD for ; Fri, 13 Aug 2010 06:03:04 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 0B6E663B101; Fri, 13 Aug 2010 06:02:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from shannon.crazycode.ca (shannon.crazycode.ca [173.203.208.70]) by mail.netbsd.org (Postfix) with ESMTP id DCFC363B100 for ; Fri, 13 Aug 2010 06:02:49 +0000 (UTC) Received: from [131.181.101.138] (unknown [131.181.101.138]) (Authenticated sender: dstebila@crazycode.ca) by shannon.crazycode.ca (Postfix) with ESMTPSA id 8822298112; Fri, 13 Aug 2010 02:04:36 -0400 (EDT) Subject: Re: deaft-gree-sedsh-ecc-08: small correction Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Douglas Stebila In-Reply-To: Date: Fri, 13 Aug 2010 16:02:45 +1000 Cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <73C6C33D-9831-4195-A3D0-9735DFA52F75@stebila.ca> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> To: Damien Miller X-Mailer: Apple Mail (2.1081) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien, I'm confused about this email I just received from you. The = draft you're referring to, draft-green-secsh-ecc-08, became RFC 5656 = back in December 2009. At this point, the only ways to make changes are = either through errata or through a new document that updates/obsoletes = the existing document. To respond to your individual points: On 2010-Aug-13, at 3:29 PM, Damien Miller wrote: > Why not drop ECMQV from the draft entirely? AFAIK it is patented, > which is enough to stop us (OpenSSH) from implementing it. I think > new KEX methods need a very good justification, since they represent > a significant part of the pre-auth attack surface. ECMQV is an optional element of RFC 5656. We received expressions of = interest for including this from some parties, and were aware of = concerns like the one you raised, and as such went for making it an = optional element. =20 > Also on the -08 draft, shouldn't the client and server in ECDH reject > public keys from the peer that are points at infinity? Are there > other degenerate values to worry about? RFC 5656 requires that all elliptic curve public keys be validated after = being received, and cites the validation algorithm from Section 3.2.2 = from SEC1, which for example includes rejecting the point at infinity. Douglas= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 12 23:49:06 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3532F3A6892 for ; Thu, 12 Aug 2010 23:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmMfSlR3pmI9 for ; Thu, 12 Aug 2010 23:49:03 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id A42EB3A681B for ; Thu, 12 Aug 2010 23:49:01 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 5561C709CB for ; Fri, 13 Aug 2010 06:49:38 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 439F563B101; Fri, 13 Aug 2010 06:49:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id E26A863B100 for ; Fri, 13 Aug 2010 06:49:21 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 8B1AEC4C11; Fri, 13 Aug 2010 15:29:52 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 49361C4AC3; Fri, 13 Aug 2010 15:29:47 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id C913A3F7F0; Fri, 13 Aug 2010 15:29:46 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id C0CEF3F7C2; Fri, 13 Aug 2010 15:29:46 +1000 (EST) Date: Fri, 13 Aug 2010 15:29:46 +1000 (EST) From: Damien Miller To: "Igoe, Kevin M." , Douglas Stebila cc: ietf-ssh@NetBSD.org Subject: Re: deaft-gree-sedsh-ecc-08: small correction In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> Message-ID: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 16 Jun 2009, Igoe, Kevin M. wrote: > In the Introduction to draft-green-secsh-ecc-08 we find > > In the interest of adding Suite B algorithms to SSH this document > adds three ECC Suite B algorithms to the Secure Shell arsenal: > Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- > Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm > (ECDSA), as well as utilizing the SHA2 family of secure hash > algorithms. > Slight error here: ECMQV is no longer part of Suite B. For sake of > correctness, I'd suggest something like the following: > > In the interest of adding Suite B algorithms to SSH this document > adds two ECC Suite B algorithms to the Secure Shell arsenal: > Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital > Signature Algorithm (ECDSA), as well as utilizing the SHA2 family > of secure hash algorithms. Additonally, support is provided for > Elliptic Curve Menezes-Qu-Vanstone (ECMQV). Why not drop ECMQV from the draft entirely? AFAIK it is patented, which is enough to stop us (OpenSSH) from implementing it. I think new KEX methods need a very good justification, since they represent a significant part of the pre-auth attack surface. Also on the -08 draft, shouldn't the client and server in ECDH reject public keys from the peer that are points at infinity? Are there other degenerate values to worry about? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 13 06:38:18 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C463A68E4 for ; Fri, 13 Aug 2010 06:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on3z3jGhZTBr for ; Fri, 13 Aug 2010 06:38:17 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id EFC623A6781 for ; Fri, 13 Aug 2010 06:38:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 7C9267085E for ; Fri, 13 Aug 2010 13:38:53 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 08F9763B101; Fri, 13 Aug 2010 13:38:39 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id C41C363B100 for ; Fri, 13 Aug 2010 13:38:37 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 84589C4C36; Fri, 13 Aug 2010 23:38:35 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 74DA7C4AC3; Fri, 13 Aug 2010 23:38:30 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 1D2B23FDA5; Fri, 13 Aug 2010 23:38:30 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 1B1B43F8D1; Fri, 13 Aug 2010 23:38:30 +1000 (EST) Date: Fri, 13 Aug 2010 23:38:30 +1000 (EST) From: Damien Miller To: Douglas Stebila cc: "Igoe, Kevin M." , ietf-ssh@NetBSD.org Subject: Re: deaft-gree-sedsh-ecc-08: small correction In-Reply-To: <73C6C33D-9831-4195-A3D0-9735DFA52F75@stebila.ca> Message-ID: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> <73C6C33D-9831-4195-A3D0-9735DFA52F75@stebila.ca> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 13 Aug 2010, Douglas Stebila wrote: > Damien, I'm confused about this email I just received from you. The > draft you're referring to, draft-green-secsh-ecc-08, became RFC > 5656 back in December 2009. At this point, the only ways to make > changes are either through errata or through a new document that > updates/obsoletes the existing document. sorry, I hadn't realised that the draft had matriculated. I'm thinking of implementing the ECDH and ECDSA parts of the draft when I return from the USA. Is anyone interested in some interop testing? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 13 07:06:09 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18E93A68F2 for ; Fri, 13 Aug 2010 07:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqNTl4Y6LEno for ; Fri, 13 Aug 2010 07:06:07 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 5BE3F3A68AC for ; Fri, 13 Aug 2010 07:06:07 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 223567093C for ; Fri, 13 Aug 2010 14:06:44 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 180ED63B101; Fri, 13 Aug 2010 14:06:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by mail.netbsd.org (Postfix) with ESMTP id C288263B100 for ; Fri, 13 Aug 2010 14:06:27 +0000 (UTC) Received: from MSCS-GH1-UEA03.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o7DD5duZ010042; Fri, 13 Aug 2010 13:05:40 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Aug 2010 09:05:45 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: deaft-gree-sedsh-ecc-08: small correction Date: Fri, 13 Aug 2010 09:05:45 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: deaft-gree-sedsh-ecc-08: small correction Thread-Index: Acs6s7WsNzunHQcfQKGGBDhPKlApTQAMylpg References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Damien Miller" , "Douglas Stebila" Cc: X-OriginalArrivalTime: 13 Aug 2010 13:05:45.0856 (UTC) FILETIME=[3E14B800:01CB3AE8] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list You are correct, MQV was thrown out of Suite B some time ago and we should rephrase this statement to reflect that. I view leaving MQV in this draft as harmless. Yes, currently there are Intellectual Property issues involving MQV, but that may well change in the future. As to checking for the point at infinity in ECDH, I'd rather have that issue addressed in a document that is clearly directed at ECDH rather than having it hidden=20 in a document that only peripherally touches ECDH. I'll be putting out a "Suite B for Secure Shell" document in the near future and plan to cover such issues in there. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On > Behalf Of Damien Miller > Sent: Friday, August 13, 2010 1:30 AM > To: Igoe, Kevin M.; Douglas Stebila > Cc: ietf-ssh@NetBSD.org > Subject: Re: deaft-gree-sedsh-ecc-08: small correction >=20 > On Tue, 16 Jun 2009, Igoe, Kevin M. wrote: >=20 > > In the Introduction to draft-green-secsh-ecc-08 we find > > > > In the interest of adding Suite B algorithms to SSH this document > > adds three ECC Suite B algorithms to the Secure Shell arsenal: > > Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- > > Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm > > (ECDSA), as well as utilizing the SHA2 family of secure hash > > algorithms. > > Slight error here: ECMQV is no longer part of Suite B. For sake of > > correctness, I'd suggest something like the following: > > > > In the interest of adding Suite B algorithms to SSH this document > > adds two ECC Suite B algorithms to the Secure Shell arsenal: > > Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital > > Signature Algorithm (ECDSA), as well as utilizing the SHA2 family > > of secure hash algorithms. Additonally, support is provided for > > Elliptic Curve Menezes-Qu-Vanstone (ECMQV). >=20 > Why not drop ECMQV from the draft entirely? AFAIK it is patented, > which is enough to stop us (OpenSSH) from implementing it. I think > new KEX methods need a very good justification, since they represent > a significant part of the pre-auth attack surface. >=20 > Also on the -08 draft, shouldn't the client and server in ECDH reject > public keys from the peer that are points at infinity? Are there > other degenerate values to worry about? >=20 > -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 13 08:52:12 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82AB13A67FB for ; Fri, 13 Aug 2010 08:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz42DHQ0ayEK for ; Fri, 13 Aug 2010 08:52:09 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id C26F43A6803 for ; Fri, 13 Aug 2010 08:52:08 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 40E3D70AC0 for ; Fri, 13 Aug 2010 15:52:45 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 3CF0E63B108; Fri, 13 Aug 2010 15:52:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.65.40]) by mail.netbsd.org (Postfix) with ESMTP id E7A1B63B100 for ; Fri, 13 Aug 2010 15:52:26 +0000 (UTC) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o7DEtVMM010524; Fri, 13 Aug 2010 14:55:31 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Aug 2010 10:55:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: deaft-gree-sedsh-ecc-08: small correction Date: Fri, 13 Aug 2010 10:55:13 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7F@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: deaft-gree-sedsh-ecc-08: small correction Thread-Index: Acs69RFxFblG3wEQRzCV850BeDALAgAAho/g References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Peter Gutmann" , , Cc: X-OriginalArrivalTime: 13 Aug 2010 14:55:13.0543 (UTC) FILETIME=[88BA3970:01CB3AF7] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Thanks Peter, I'm happy to find this issue has been already been addressed. > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Friday, August 13, 2010 10:37 AM > To: djm@mindrot.org; douglas@stebila.ca; Igoe, Kevin M. > Cc: ietf-ssh@NetBSD.org > Subject: RE: deaft-gree-sedsh-ecc-08: small correction >=20 > "Igoe, Kevin M." writes: >=20 > >As to checking for the point at infinity in ECDH, I'd rather have that > issue > >addressed in a document that is clearly directed at ECDH rather than > having > >it hidden in a document that only peripherally touches ECDH. I'll be > putting > >out a "Suite B for Secure Shell" document in the near future and plan > to cover > >such issues in there. >=20 > Shouldn't this check be automatic anyway for a (correct) > implementation? The > standard that defines ECC use (keygen, key checking, data formats, > etc), > X9.62, already mandates this check (although for some reason the RFC > references it as informative rather than normative and gives the SECG > doc as > the primary reference when pretty much everything else uses X9.62, and > AFAIK > the SECG stuff was derived from the earlier X9.62 work), so if you > implement > ECC correctly than you already do this check. In any case the text > says: >=20 > All elliptic curve public keys MUST be validated after they are > received. An example of a validation algorithm can be found in > Section 3.2.2 of [SEC1]. If a key fails validation, the key > exchange > MUST fail. >=20 > so it appears this is already covered. The checks I have, from X9.62, > are: >=20 > /* Verify that the public key parameter sizes are valid: >=20 > qx, qy >=3D MIN_PKCSIZE_ECC, qx, qy <=3D p - 1 */ >=20 > /* Verify that Q is not the point at infinity */ >=20 > /* Verify that qx, qy are elements in the field Fq, i.e. in the > range > 0...p - 1 */ >=20 > /* Verify that qy^2 is congruent to qx^3 + a*qx + b (mod p) */ >=20 > /* Verify that n * Q is the point at infinity */ >=20 > If that's sufficient for checking Q then the existing doc already > covers > things. >=20 > Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 13 08:52:40 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C532F3A68F6 for ; Fri, 13 Aug 2010 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zd9blIsWaX7 for ; Fri, 13 Aug 2010 08:52:37 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 0B94F3A6803 for ; Fri, 13 Aug 2010 08:52:37 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id BEBB570905 for ; Fri, 13 Aug 2010 15:53:13 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 0705963B100; Fri, 13 Aug 2010 15:52:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.65.40]) by mail.netbsd.org (Postfix) with ESMTP id 34FC163B104 for ; Fri, 13 Aug 2010 15:52:28 +0000 (UTC) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o7DEpvMM009258; Fri, 13 Aug 2010 14:51:57 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Aug 2010 10:51:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: deaft-gree-sedsh-ecc-08: small correction Date: Fri, 13 Aug 2010 10:51:39 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7E@MSIS-GH1-UEA06.corp.nsa.gov> In-reply-to: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: deaft-gree-sedsh-ecc-08: small correction Thread-Index: Acs6s7WsNzunHQcfQKGGBDhPKlApTQAMylpgAAOc5aA= References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034955@MSIS-GH1-UEA06.corp.nsa.gov> <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp.nsa.gov> From: "Igoe, Kevin M." To: "Igoe, Kevin M." , "Damien Miller" , "Douglas Stebila" Cc: X-OriginalArrivalTime: 13 Aug 2010 14:51:39.0796 (UTC) FILETIME=[09530540:01CB3AF7] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Opps, mea culpa. I see are referring to draft-green-secsh-ecc-08, now known as RFC 5656. My responses were in reference to draft-igoe-secsh-x509v3-05. Given it has already been published as an RFC, the inclusion of MQV is Suite B is an historical artifact that reflects the early genesis of Suite B, and as such can stand. The point at infinity is a worthy observation perhaps best=20 addressed by an errata? I'm not terribly familiar with the IESG errata process. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On > Behalf Of Igoe, Kevin M. > Sent: Friday, August 13, 2010 9:06 AM > To: Damien Miller; Douglas Stebila > Cc: ietf-ssh@NetBSD.org > Subject: RE: deaft-gree-sedsh-ecc-08: small correction >=20 > You are correct, MQV was thrown out of Suite B some time ago > and we should rephrase this statement to reflect that. I > view leaving MQV in this draft as harmless. Yes, currently > there are Intellectual Property issues involving MQV, but that > may well change in the future. >=20 > As to checking for the point at infinity in ECDH, I'd > rather have that issue addressed in a document that is > clearly directed at ECDH rather than having it hidden > in a document that only peripherally touches ECDH. > I'll be putting out a "Suite B for Secure Shell" document > in the near future and plan to cover such issues in there. >=20 >=20 > > -----Original Message----- > > From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On > > Behalf Of Damien Miller > > Sent: Friday, August 13, 2010 1:30 AM > > To: Igoe, Kevin M.; Douglas Stebila > > Cc: ietf-ssh@NetBSD.org > > Subject: Re: deaft-gree-sedsh-ecc-08: small correction > > > > On Tue, 16 Jun 2009, Igoe, Kevin M. wrote: > > > > > In the Introduction to draft-green-secsh-ecc-08 we find > > > > > > In the interest of adding Suite B algorithms to SSH this > document > > > adds three ECC Suite B algorithms to the Secure Shell arsenal: > > > Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve > Diffie- > > > Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm > > > (ECDSA), as well as utilizing the SHA2 family of secure hash > > > algorithms. > > > Slight error here: ECMQV is no longer part of Suite B. For sake of > > > correctness, I'd suggest something like the following: > > > > > > In the interest of adding Suite B algorithms to SSH this > document > > > adds two ECC Suite B algorithms to the Secure Shell arsenal: > > > Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital > > > Signature Algorithm (ECDSA), as well as utilizing the SHA2 > family > > > of secure hash algorithms. Additonally, support is provided for > > > Elliptic Curve Menezes-Qu-Vanstone (ECMQV). > > > > Why not drop ECMQV from the draft entirely? AFAIK it is patented, > > which is enough to stop us (OpenSSH) from implementing it. I think > > new KEX methods need a very good justification, since they represent > > a significant part of the pre-auth attack surface. > > > > Also on the -08 draft, shouldn't the client and server in ECDH reject > > public keys from the peer that are points at infinity? Are there > > other degenerate values to worry about? > > > > -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Aug 13 09:10:09 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388FC3A69F7 for ; Fri, 13 Aug 2010 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=1.509, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2zQu+Uqo683 for ; Fri, 13 Aug 2010 09:10:05 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 9739B3A696E for ; Fri, 13 Aug 2010 09:10:02 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 53C4A709B7 for ; Fri, 13 Aug 2010 16:10:39 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 6952163B101; Fri, 13 Aug 2010 16:10:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id B17E963B100 for ; Fri, 13 Aug 2010 16:10:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1281715823; x=1313251823; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20djm@mindrot.org,=20douglas@stebila.ca,=20kmigoe@ns a.gov|Subject:=20RE:=20deaft-gree-sedsh-ecc-08:=20small =20correction|Cc:=20ietf-ssh@NetBSD.org|In-Reply-To:=20<8 0F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp .nsa.gov>|Message-Id:=20|Date:=20Sat,=2014=20Aug=202010=2002:37: 26=20+1200; bh=6uv20/GVuguwZ6MtMDQhjZSrMSgUYXNoUrlJK6IjRPI=; b=L4Pjeb+skhnYVMXVlsw346ih6NeXrXB51jebssYVodaMuMZfmX+ReqWC EnC+VhJhtJYmdbEE4s3TNHvpzY12aqxcUcx4IdliSsZ9IVM6ya1bogD/W xBT8Z/fm9TFtSPMl28eKGopGg6y1OxQdKdikBZhjDRD/UG5E/bZ+lIRcX M=; X-IronPort-AV: E=Sophos;i="4.55,363,1278244800"; d="scan'208";a="20757514" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Aug 2010 02:37:26 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OjvNu-0004sH-7a; Sat, 14 Aug 2010 02:37:26 +1200 From: Peter Gutmann To: djm@mindrot.org, douglas@stebila.ca, kmigoe@nsa.gov Subject: RE: deaft-gree-sedsh-ecc-08: small correction Cc: ietf-ssh@NetBSD.org In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034A7D@MSIS-GH1-UEA06.corp.nsa.gov> Message-Id: Date: Sat, 14 Aug 2010 02:37:26 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "Igoe, Kevin M." writes: >As to checking for the point at infinity in ECDH, I'd rather have that issue >addressed in a document that is clearly directed at ECDH rather than having >it hidden in a document that only peripherally touches ECDH. I'll be putting >out a "Suite B for Secure Shell" document in the near future and plan to cover >such issues in there. Shouldn't this check be automatic anyway for a (correct) implementation? The standard that defines ECC use (keygen, key checking, data formats, etc), X9.62, already mandates this check (although for some reason the RFC references it as informative rather than normative and gives the SECG doc as the primary reference when pretty much everything else uses X9.62, and AFAIK the SECG stuff was derived from the earlier X9.62 work), so if you implement ECC correctly than you already do this check. In any case the text says: All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail. so it appears this is already covered. The checks I have, from X9.62, are: /* Verify that the public key parameter sizes are valid: qx, qy >= MIN_PKCSIZE_ECC, qx, qy <= p - 1 */ /* Verify that Q is not the point at infinity */ /* Verify that qx, qy are elements in the field Fq, i.e. in the range 0...p - 1 */ /* Verify that qy^2 is congruent to qx^3 + a*qx + b (mod p) */ /* Verify that n * Q is the point at infinity */ If that's sufficient for checking Q then the existing doc already covers things. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 17 14:45:59 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504DD3A6853 for ; Tue, 17 Aug 2010 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taTCYmLqvz7A for ; Tue, 17 Aug 2010 14:45:56 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 8935B3A6838 for ; Tue, 17 Aug 2010 14:45:56 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 80D43711C1 for ; Tue, 17 Aug 2010 21:46:30 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id C399363B101; Tue, 17 Aug 2010 21:46:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 8B3D263B100 for ; Tue, 17 Aug 2010 21:46:14 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id B6E02C4AE0; Wed, 18 Aug 2010 07:46:11 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 412AAC4AA7; Wed, 18 Aug 2010 07:46:06 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id EF1573F9BB; Wed, 18 Aug 2010 07:46:05 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id EE4B43F891; Wed, 18 Aug 2010 07:46:05 +1000 (EST) Date: Wed, 18 Aug 2010 07:46:05 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: douglas@stebila.ca, kmigoe@nsa.gov, ietf-ssh@NetBSD.org Subject: RE: deaft-gree-sedsh-ecc-08: small correction In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, 14 Aug 2010, Peter Gutmann wrote: > All elliptic curve public keys MUST be validated after they are > received. An example of a validation algorithm can be found in > Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange > MUST fail. > > so it appears this is already covered. The checks I have, from X9.62, are: > > /* Verify that the public key parameter sizes are valid: > > qx, qy >= MIN_PKCSIZE_ECC, qx, qy <= p - 1 */ What do you use as this minimium? AFAIK SEC1 doesn't specify this check, but I guess it should be at least 2 and probabalistically something less than p/4 or so (for p of a hundred bits or more) -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Aug 17 19:35:26 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0B83A67B3 for ; Tue, 17 Aug 2010 19:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuWiTW7QQH6h for ; Tue, 17 Aug 2010 19:35:23 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 283B53A65A5 for ; Tue, 17 Aug 2010 19:35:23 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id C986E71547 for ; Wed, 18 Aug 2010 02:35:57 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 0A5D463B101; Wed, 18 Aug 2010 02:35:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id B863F63B100 for ; Wed, 18 Aug 2010 02:35:42 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 358FBC4AD2; Wed, 18 Aug 2010 12:35:39 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 57B09C4AA7; Wed, 18 Aug 2010 12:35:33 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id CB8073FBB8; Wed, 18 Aug 2010 12:35:32 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id C7F213F756; Wed, 18 Aug 2010 12:35:32 +1000 (EST) Date: Wed, 18 Aug 2010 12:35:32 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: douglas@stebila.ca, kmigoe@nsa.gov, ietf-ssh@NetBSD.org Subject: RE: deaft-gree-sedsh-ecc-08: small correction In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 18 Aug 2010, Damien Miller wrote: > On Sat, 14 Aug 2010, Peter Gutmann wrote: > > > All elliptic curve public keys MUST be validated after they are > > received. An example of a validation algorithm can be found in > > Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange > > MUST fail. > > > > so it appears this is already covered. The checks I have, from X9.62, are: > > > > /* Verify that the public key parameter sizes are valid: > > > > qx, qy >= MIN_PKCSIZE_ECC, qx, qy <= p - 1 */ > > What do you use as this minimium? AFAIK SEC1 doesn't specify this check, but > I guess it should be at least 2 and probabalistically something less than > p/4 or so (for p of a hundred bits or more) oops, I meant "a number about 1/4 the length of p" From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 18 02:32:25 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70FC3A68C5 for ; Wed, 18 Aug 2010 02:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.829 X-Spam-Level: X-Spam-Status: No, score=-4.829 tagged_above=-999 required=5 tests=[AWL=1.770, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYIVDY7pGiic for ; Wed, 18 Aug 2010 02:32:20 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 922653A6A27 for ; Wed, 18 Aug 2010 02:32:20 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 435C670736 for ; Wed, 18 Aug 2010 09:32:55 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id EB43963B101; Wed, 18 Aug 2010 09:32:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx2.auckland.ac.nz", Issuer "AusCERT Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 5645563B100 for ; Wed, 18 Aug 2010 09:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1282123957; x=1313659957; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20djm@mindrot.org,=20pgut001@cs.auckland.ac.nz |Subject:=20RE:=20deaft-gree-sedsh-ecc-08:=20small=20corr ection|Cc:=20douglas@stebila.ca,=20ietf-ssh@NetBSD.org, =20kmigoe@nsa.gov|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2018 =20Aug=202010=2021:32:29=20+1200; bh=/6s0ujKZot1pQMLz3vDI61+bjL/DN6FpL/0go2GpJbM=; b=ptvIZHi2DABUOcn9zOlytCic24NB3N4csNFzCOTIx7U7f98hF3oK+VUk cgyAZuquLrDKJEm4Mt9EKK9Ou54JEsj7CkSyIKriwXnndukVzRlK6T8ay 51sPi7XOB6zCiiCSLnSeVv8IsUu5BUDr9vo6goSlz3BVQh0GRrjBFalpW 8=; X-IronPort-AV: E=Sophos;i="4.56,226,1280664000"; d="scan'208";a="21583447" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Aug 2010 21:32:30 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Olf0X-0003Nm-Sl; Wed, 18 Aug 2010 21:32:29 +1200 From: Peter Gutmann To: djm@mindrot.org, pgut001@cs.auckland.ac.nz Subject: RE: deaft-gree-sedsh-ecc-08: small correction Cc: douglas@stebila.ca, ietf-ssh@NetBSD.org, kmigoe@nsa.gov In-Reply-To: Message-Id: Date: Wed, 18 Aug 2010 21:32:29 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > On Sat, 14 Aug 2010, Peter Gutmann wrote: >> > /* Verify that the public key parameter sizes are valid: >> > >> > qx, qy >= MIN_PKCSIZE_ECC, qx, qy <= p - 1 */ >> >> What do you use as this minimium? AFAIK SEC1 doesn't specify this check, but >> I guess it should be at least 2 and probabalistically something less than >> p/4 or so (for p of a hundred bits or more) > >oops, I meant "a number about 1/4 the length of p" I use ( 256 - 192 ) bits, assuming that a value for which the first 64 (or more) bits are zero is a sign of a problem rather than just a really unlikely coincidence. The spec doesn't require this (it could be only two bits long, with a probability of 2^-254), but it seems like prudent engineering practice to reject values like this. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 07:12:02 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED753A6AF5 for ; Wed, 25 Aug 2010 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEemB115FLdP for ; Wed, 25 Aug 2010 07:11:58 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 4E95F3A69F9 for ; Wed, 25 Aug 2010 07:11:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id A4BD8708A0 for ; Wed, 25 Aug 2010 14:12:30 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 718CC63B101; Wed, 25 Aug 2010 14:12:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 1225763B100 for ; Wed, 25 Aug 2010 14:12:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA20207; Wed, 25 Aug 2010 10:12:15 -0400 (EDT) Date: Wed, 25 Aug 2010 10:12:15 -0400 (EDT) From: der Mouse Message-Id: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 10:02:36 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: fds beyond 0/1/2 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I had occasion to wish that ssh supported running remote commands with fds other than 0, 1, and 2 connected to useful things. Has anyone written up a spec for an extension to support this? I don't recall seeing any, but that doesn't prove anything. If not, I've got some ideas I can write up and float for comment. Or, if nobody but me cares, I suppose I can just hack something together and forget the issue. :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 08:19:22 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C606D3A6A4F for ; Wed, 25 Aug 2010 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wZReamTvcEF for ; Wed, 25 Aug 2010 08:19:21 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 2DFD33A6A01 for ; Wed, 25 Aug 2010 08:19:21 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id AF8B170ACD for ; Wed, 25 Aug 2010 15:19:53 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 575F863B104; Wed, 25 Aug 2010 15:19:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 957D463B100 for ; Wed, 25 Aug 2010 15:19:31 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA20817; Wed, 25 Aug 2010 11:19:29 -0400 (EDT) Date: Wed, 25 Aug 2010 11:19:29 -0400 (EDT) From: der Mouse Message-Id: <201008251519.LAA20817@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 11:08:22 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> I had occasion to wish that ssh supported running remote commands >> with fds other than 0, 1, and 2 connected to useful things. >> Has anyone written up a spec for an extension to support this? I >> don't recall seeing any, but that doesn't prove anything. > I haven't seen any. Then I probably haven't just missed it. > I guess one ought to use MSG_CHANNEL_EXTENDED_DATA for the actual > data, but then you need some session handshaking to set up which fd:s > should be opened and which ids they should use in > MSG_CHANNEL_EXTENDED_DATA. Right. I spent most of my last train trip thinking about this and blocking out roughly how I'd do it, and what I came up with totally fits with what you sketch here. > All fd:s of the channel would then use a single window (or rather, > one in each direction) for flow control. Right. > I take it this could be useful for both directions, although with the > client in chanrge of setting everything up. Yes. So far it seems your thoughts and mine are tracking pretty closely, so I'm probably not totally off in the weeds. Hm, this actually raises a potential issue: we really should have separate back-pressure on each fd, so that failure to consume data from a particular fd does not wedge the whole channel. > Do you want to be able to setup bidirectional fd:s as well? Yes, largely because I see no particular reason to forbid it, and it can be useful for programmatic use if nothing else. The protocol I have blocked out even supports requesting forwarding with data transfer in neither direction, though I would expect servers to reject such attempts unless-and-until someone invents a way to make them useful. >> If not, I've got some ideas I can write up and float for comment. >> If nobody but me cares, I suppose I can just hack something together >> and forget the issue. :) > I'm somewhat interested, but I'm not going to put in any real work > any time soon. I'm not asking anyone to. I'd be interested in any thoughts anyone has on the subject, but I don't expect anyone but me to be doing any coding on it. Given that we've lasted this long without anyone caring enough to say anything public about it, it's obviously not a high priority for most people. I'll send another note to the list in a few minutes with what I have so far. It actually includes two extensions which, while strictly orthogonal to one another, synergize nicely: one for fd forwarding and one for indicating EOF on a data stream without indicating EOF on the whole channel. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 08:32:03 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D08D3A6AEC for ; Wed, 25 Aug 2010 08:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.054 X-Spam-Level: X-Spam-Status: No, score=-5.054 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmidXCpP0CKb for ; Wed, 25 Aug 2010 08:32:01 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 335253A6988 for ; Wed, 25 Aug 2010 08:32:00 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id B9325714A5 for ; Wed, 25 Aug 2010 15:32:32 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id DDE4563B101; Wed, 25 Aug 2010 15:32:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 3105063B100 for ; Wed, 25 Aug 2010 15:32:12 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA20885; Wed, 25 Aug 2010 11:32:11 -0400 (EDT) Date: Wed, 25 Aug 2010 11:32:11 -0400 (EDT) From: der Mouse Message-Id: <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 11:23:19 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> I've got some ideas I can write up and float for comment. Here's what I have. Comments are invited. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B This file describes the fd-forward@rodents.montreal.qc.ca and data-eof@rodents.montreal.qc.ca requests, and the facilities they are designed to provide. fd-forward@rodents.montreal.qc.ca is both a global request and a channel request; data-eof@rodents.montreal.qc.ca is a channel request. While they are related, in that each is more useful in conjunction with the other, they are, strictly, orthogonal, so they are described separately. For brevity, fd-forward@rodents.montreal.qc.ca is abbreviated to fd-forward below; similarly, data-eof@rodents.montreal.qc.ca is abbreviated to data-eof. There are various MOUSSH_* constants used in the descriptions below. Their values are given in a table at the end of this document. ---------------- fd-forward@rodents.montreal.qc.ca Standard ssh has no way to handle running remote processes with more than one input channel (stdin, implemented with SSH_MSG_CHANNEL_DATA from client to server) or more than two output channels (stdout, implemented with SSH_MSG_CHANNEL_DATA from server to client, and stderr, implemented with SSH_MSG_CHANNEL_EXTENDED_DATA of type SSH_EXTENDED_DATA_STDERR from server to client). This request supports forwarding other file descriptors in either or both directions. It is fundamentally based on a file descriptor model more or less like POSIX's; non-POSIX OSes will find it difficult to implement to approximately the degree that they do not match the POSIX file descriptor model. As a global request, fd-forward may be sent only by the client. It is used to enquire whether the server supports this protocol. In this use, it MUST have want-reply set true and MUST have zero bytes of request-specific data; servers supporting the protocol described here MUST respond to such a request with with SSH_MSG_REQUEST_SUCCESS and zero bytes of response-specific data. Global requests with want-reply false and/or nonempty request-specific data are reserved for future specification; servers MUST respond to any such with SSH_MSG_REQUEST_FAILURE. Clients MUST respond to any fd-forward global requests with SSH_MSG_REQUEST_FAILURE, regardless of want-reply and associated data. As a channel request, fd-forward may be issued by the client on any channel of type "session" which has not yet had an "exec" or "shell" request (or any other requests of similar semantics - collectively, exec-style requests) made on it. (moussh implements no exec-style requests other than standard exec and shell requests as of this writing.) It also MUST have want-reply set true. Using it in violation of any of these requirements (on a channel of any other type, on a "session" channel which has had an exec-style request made on it, or with want-reply false) is reserved for future specification and MUST draw SSH_MSG_REQUEST_FAILURE. The server may also issue fd-forward channel requests, but only as outlined below, in response to client-issued fd-forward channel requests; other use in the server->client direction is similarly reserved and likewise MUST elicit SSH_MSG_REQUEST_FAILURE. The same is true of requests in either direction which meet the above criteria but carry request-specific data (or lack thereof) violating the syntax below. Data for forwarded fds is carried in SSH_MSG_CHANNEL_EXTENDED_DATA messages. The data_type_code values for these messages are selected, at forwarding setup time, by the sender of the data. Current expectation is that they will be selected from the private-use range 0xfe000000-0xffffffff, but this is not a requirement of this specification; if suitable IETF standardization occurs, they may be drawn from the 0-0xfdffffff range. (A descriptor which carries data in both directions thus has two associated data_type_codes, one for each direction.) Forwarding of multiple fds may be requested by sending multiple channel requests or by sending multiple blobs in a single channel request, or any combination of the two. However, requesting forwarding more than once for a given fd, whether in a single message or in different messages, is an error. In this case, the server is permitted to reject all of the relevant requests; it is also permitted to accept one of them and reject the rest. Similarly, requesting multiple forwardings using identical data_type_code values is an error; at most one of any such set may be accepted. In either case, if one is accepted, there is no requirement which one it is; it will usually be the first, for some sense of "first" convenient for the implementation, but this is not a requirement - the only specification here is that at most one request be accepted for a given fd on a given channel, and at most one for any given data_type_code on a given channel. (This applies even if the requests in question specify identical forwardings.) The request-specific data in the request MUST consist of byte MOUSSH_FDFWD_MSG_REQUEST followed by a stream of forwarding request blobs. Each of these blobs consists of uint32 fd byte flags (additional data may follow; see below) fd is the descriptor to be forwarded. (This protocol has no support for descriptor numbers that do not fit in a uint32.) flags is a bitmask of flags: 0x01 Input 0x02 Output 0x04 Inessential 0xf8 Reserved for future specification, must be 0 If the input flag is set, data may flow from client to server. In this case, there is one uint32 of additional data after the flags byte, which is the data_type_code for data on this fd in this direction. If the input flag is clear, there is no way for data to flow in the client-to-server direction on this fd. If the output flag is set, data may flow from server to client. The data_type_code for this data is selected by the server and is returned in the response (see below). If the output flag is clear, there is no way for data to flow in the server-to-client direction on this fd. If the inessential flag is set, failure to establish this forwarding may be benign; if clear, it is always fatal. See below for details. It is legal (though mostly useless) for a request to carry zero request blobs, ie, for its request-specific data to contain just the MOUSSH_FDFWD_MSG_REQUEST byte. Such a request must be responded to as usual, with the response carrying zero response blobs. It is legal for a request blob to specify any of the four possible combinations of the input and output flags, but, depending on the facilities available on the server, some of them may cause the forwarding request to be rejected. (Given only the facilities specified here, a forwarding with neither input nor output enabled is fairly useless, but there's no reason to forbid it, and someone may find a use for it, or future expansion of this protocol may make such forwardings useful.) Because these requests MUST have want-reply set true, they will always draw an ssh-level response. If the request conforms to the above syntax, this MUST be SSH_MSG_CHANNEL_SUCCESS, and the server MUST generate a channel request in the other direction as described below. Otherwise, the ssh-level response MUST be SSH_MSG_CHANNEL_FAILURE, and the server generates no further response and does not process any of the forwarding request blobs contained in the erroneous message. The channel request generated by the server in response to a MOUSSH_FDFWD_MSG_REQUEST request which draws SSH_MSG_CHANNEL_SUCCESS MUST be sent with want-reply false; its request-specific data contains byte MOUSSH_FDFWD_MSG_RESPONSE followed by a stream of forwarding response blobs, exactly one for each request blob in the request; they are in corresponding order (that is, if request blob X occurs before request blob Y in the MOUSSH_FDFWD_MSG_REQUEST data, then the response blob for request blob X must occur before the response blob for request blob Y in the resulting MOUSSH_FDFWD_MSG_RESPONSE). MOUSSH_FDFWD_MSG_RESPONSE messages MUST always occur in the same order as the MOUSSH_FDFWD_MSG_REQUEST messages they are responses to. This MOUSSH_FDFWD_MSG_RESPONSE fd-forward channel request MUST occur after the SSH_MSG_CHANNEL_SUCCESS generated for the corresponding MOUSSH_FDFWD_MSG_REQUEST fd-forward channel request. Each response blob contains either a failure indication, with a reason message, or a success indication, possibly with a data_type_code (depending on whether the corresponding request blob had its output bit set). If the forwarding request is rejected, the response blob contains byte MOUSSH_FDFWD_REQ_REJECTED string reason The reason string gives the reason for the rejection, if the server chooses to provide one; if not, it is zero-length string. (RFC4251 section 4.5 is relevant to the generation of these strings.) If the corresponding request blob's inessential bit was set, this failure may (but not must) be benign, in which case the server should operate as if the corresponding forwarding request had not been made. If the inessential bit was clear, or it was set but the server chooses to consider the failure fatal nevertheless, then the server MUST reject any following exec-style request on this channel. If the forwarding request is accepted and the corresponding request blob's output flag bit was clear, the response blob contains byte MOUSSH_FDFWD_REQ_ACCEPTED If the forwarding request is accepted and the corresponding request blob's output flag bit was set, the response blob contains byte MOUSSH_FDFWD_REQ_ACCEPTED uint32 data_type_code where the data_type_code will be used for server-to-client data for this fd. There are often some conditions which can cause a forwarding to fail but which cannot be detected until an exec-style request is attempted. To deal with these cases, if any fd forwarding requests were accepted on a channel, then an exec-style request on that channel MUST cause the server to generate, before its normal response to the request, one or more fd-forward channel requests, with want-reply set false, whose request-specific data consists of byte MOUSSH_FDFWD_MSG_STATUS followed by a stream of zero or more status blobs. If no fd forwardings were accepted, the server MAY generate one or more MOUSSH_FDFWD_MSG_STATUS requests bearing zero status blobs (though, if the client has not sent any fd-forward requests, the server MUST be prepared for any such requests to fail, because the client may not implement this protocol at all). Clients MUST NOT fail such channel requests, even if they have not requested any forwardings. (There's no real use for such MOUSSH_FDFWD_MSG_STATUS requests from a protocol standpoint, but implementations may find them convenient.) Each status blob contains the status for one fd for which a forwarding request has been accepted; each accepted forwarding must be represented exactly once in the status blobs sent, though there are no restrictions on the order in which the status blobs occur, and no restrictions except message size on the way the collection of status blobs are grouped into MOUSSH_FDFWD_MSG_STATUS messages. However, all accepted forwarding requests' status blobs MUST be sent before the usual response to the exec-style request occurs, and MOUSSH_FDFWD_MSG_STATUS requests MUST NOT be sent under any other circumstances (before receiving an exec-style request or after sending the usual response to it, or sent by the client under any circumstances). The status blob for a forwarding which succeeds contains uint32 fd byte MOUSSH_FDFWD_STAT_WORKED whereas that for a forwading which fails contains uint32 fd byte MOUSSH_FDFWD_STAT_FAILED string reason with the reason string being as described for MOUSSH_FDFWD_REQ_REJECTED. Note that if a forawrding request whose inessential bit was clear fails at this point, the exec-family request MUST fail, even if it otherwise would have succeeded. It is not a violation of this spec to use these facilities to request forwarding for fd numbers 0, 1, or 2, but most servers will reject such attempts (because they use those fds for the standard protocol's input, output, and error streams). This facility has one major known problem: there is only one window for data per direction, shared by all data streams. We need a way to support back-pressure on each forwarded fd independently. Question: would it be better to do this within a single channel framework, or would it be better to open new channels and somehow associate them with this channel? I'm leaning towards the former, because we have the same problem already with stdout and stderr (for example, if you run "ssh foo producer | consumer" and consumer blocks long enough for pipes to fill up, an error message from producer on stderr will get blocked behind the stdout data). Question: is it reasonable to require generating an SSH_MSG_REQUEST_FAILURE in response to a request with want-reply set false? Perhaps ths spec should specify less about want-reply? The standard's text appears somewhat ambiguous. ---------------- data-eof@rodents.montreal.qc.ca Standard ssh has no way to indicate EOF on one data flow without indicating EOF on the entire channel. For input, this is not a problem, since there is only one data flow, but it is an issue for output, and, if any input fds are forwarded with fd-forward, it can be a problem for input too. We deal with this issue with data-eof channel requests. To indicate EOF on the main data stream, the one carried via SSH_MSG_CHANNEL_DATA, a sender sends a data-eof request whose request-specific body consists of byte MOUSSH_EOF_MAIN To indicate EOF on an extended data stream, one carried via SSH_MSG_CHANNEL_EXTENDED_DATA, the sender sends a data-eof request whose request-specific body consists of byte MOUSSH_EOF_EXTENDED uint32 data_type_code where data_type_code is, of course, the data_type_code whose extended data stream is being terminated. It is a protocol error to send an SSH_MSG_CHANNEL_DATA message on a channel after sending MOUSSH_EOF_MAIN on that channel, or SSH_MSG_CHANNEL_EXTENDED_DATA with a particular data_type_code after sending MOUSSH_EOF_EXTENDED with that data_type_code. These are valid with either setting of want-reply, though of course they will normally be sent with want-reply set true. If the request is rejected, it is up to the sender to decide what to do. In some circumstances it will be appropriate to ignore the failure, allowing the data stream to remain in operation as far as the receiver is concerned; in others, a more appropriate action would be to send SSH_MSG_CHANNEL_EOF, closing down all data streams in that direction. Like SSH_MSG_CHANNEL_EOF, MOUSSH_EOF_MAIN and MOUSSH_EOF_EXTENDED do not require or consume channel window space. Also like SSH_MSG_CHANNEL_EOF, indicating EOF on a data stream has no effect on any data flowing in the other direction. ---------------- MOUSSH_* values Here are the various MOUSSH_* values. Note that these sometimes are distinct even though they don't need to be; for example, MOUSSH_FDFWD_MSG_* values occur in a different context than MOUSSH_FDFWD_REQ_* values and thus could reuse numeric values. This is done this way largely to improve ease of finding bugs. But note that the MOUSSH_FDFWD_* values used by fd-forward messages do overlap with the MOUSSH_EOF_* values used by data-eof messages; this is because they are conceptually orthogonal capabilities. MOUSSH_FDFWD_MSG_REQUEST 1 MOUSSH_FDFWD_MSG_RESPONSE 2 MOUSSH_FDFWD_MSG_STATUS 3 MOUSSH_FDFWD_REQ_ACCEPTED 4 MOUSSH_FDFWD_REQ_REJECTED 5 MOUSSH_FDFWD_STAT_WORKED 6 MOUSSH_FDFWD_STAT_FAILED 7 MOUSSH_EOF_MAIN 1 MOUSSH_EOF_EXTENDED 2 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 08:41:51 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E63A3A6B44 for ; Wed, 25 Aug 2010 08:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtCSVBRx2S2E for ; Wed, 25 Aug 2010 08:41:50 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 4CCC03A6B3D for ; Wed, 25 Aug 2010 08:41:50 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id C462F71152 for ; Wed, 25 Aug 2010 15:42:22 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 6E02363B101; Wed, 25 Aug 2010 15:42:08 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 0FBDE63B100 for ; Wed, 25 Aug 2010 15:42:06 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PFg03T000315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 15:42:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7PDpiSP014689; Wed, 25 Aug 2010 15:41:59 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 530790381282750881; Wed, 25 Aug 2010 08:41:21 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 08:41:21 -0700 Date: Wed, 25 Aug 2010 10:41:16 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 Message-ID: <20100825154113.GT17097@oracle.com> References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 25, 2010 at 11:32:11AM -0400, der Mouse wrote: > >> I've got some ideas I can write up and float for comment. > > Here's what I have. Comments are invited. I like the idea, though I'd like to see how it'd be used from a typical Unix command-line. I'm guessing something like a CLI option to list file descripto numbers to forward, something like "ssh -r 0,1,2,5,7 ..." > As a global request, fd-forward may be sent only by the client. It is > used to enquire whether the server supports this protocol. In this > use, it MUST have want-reply set true and MUST have zero bytes of > request-specific data; servers supporting the protocol described here > MUST respond to such a request with with SSH_MSG_REQUEST_SUCCESS and > zero bytes of response-specific data. Global requests with want-reply > false and/or nonempty request-specific data are reserved for future > specification; servers MUST respond to any such with > SSH_MSG_REQUEST_FAILURE. Clients MUST respond to any fd-forward global > requests with SSH_MSG_REQUEST_FAILURE, regardless of want-reply and > associated data. Why is a global request needed? > As a channel request, fd-forward may be issued by the client on any > channel of type "session" which has not yet had an "exec" or "shell" > request (or any other requests of similar semantics - collectively, > exec-style requests) made on it. (moussh implements no exec-style > requests other than standard exec and shell requests as of this > writing.) It also MUST have want-reply set true. Using it in > violation of any of these requirements (on a channel of any other type, > on a "session" channel which has had an exec-style request made on it, > or with want-reply false) is reserved for future specification and MUST > draw SSH_MSG_REQUEST_FAILURE. The server may also issue fd-forward > channel requests, but only as outlined below, in response to > client-issued fd-forward channel requests; other use in the > server->client direction is similarly reserved and likewise MUST elicit > SSH_MSG_REQUEST_FAILURE. The same is true of requests in either > direction which meet the above criteria but carry request-specific data > (or lack thereof) violating the syntax below. I agree with the design based on a channel request. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 08:59:06 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711BE3A69D0 for ; Wed, 25 Aug 2010 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaENq1Bcn5Iz for ; Wed, 25 Aug 2010 08:59:05 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 635663A67A5 for ; Wed, 25 Aug 2010 08:59:05 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 6D69570AF4 for ; Wed, 25 Aug 2010 15:59:37 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 218C763B104; Wed, 25 Aug 2010 15:59:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 8588E63B101 for ; Wed, 25 Aug 2010 15:59:19 +0000 (UTC) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o7PEtPd4026782; Wed, 25 Aug 2010 16:55:25 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o7PEtOwA026781; Wed, 25 Aug 2010 16:55:24 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: der Mouse Cc: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> Date: Wed, 25 Aug 2010 16:55:24 +0200 In-Reply-To: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Wed, 25 Aug 2010 10:12:15 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list der Mouse writes: > I had occasion to wish that ssh supported running remote commands with > fds other than 0, 1, and 2 connected to useful things. > > Has anyone written up a spec for an extension to support this? I don't > recall seeing any, but that doesn't prove anything. I haven't seen any. I guess one ought to use MSG_CHANNEL_EXTENDED_DATA for the actual data, but then you need some session handshaking to set up which fd:s should be opened and which ids they should use in MSG_CHANNEL_EXTENDED_DATA. All fd:s of the channel would then use a single window (or rather, one in each direction) for flow control. I take it this could be useful for both directions, although with the client in chanrge of setting everything up. Do you want to be able to setup bidirectional fd:s as well? That's more obscure, at least in the context of shell scripting. > If not, I've got some ideas I can write up and float for comment. > if nobody but me cares, I suppose I can just hack something together > and forget the issue. :) I'm somewhat interested, but I'm not going to put in any real work any time soon. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 10:47:52 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709343A6B49 for ; Wed, 25 Aug 2010 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIkmaGvoGEw2 for ; Wed, 25 Aug 2010 10:47:51 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 33CAF3A6964 for ; Wed, 25 Aug 2010 10:47:51 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id AB52C70952 for ; Wed, 25 Aug 2010 17:48:23 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id EEFA063B104; Wed, 25 Aug 2010 17:48:09 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 4EA6163B101 for ; Wed, 25 Aug 2010 17:48:07 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1OoIos-0003dD-No; Wed, 25 Aug 2010 17:27:22 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <201008251519.LAA20817@Sparkle.Rodents-Montreal.ORG> Subject: Re: fds beyond 0/1/2 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 25 Aug 2010 17:27:22 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list der Mouse wrote: > Hm, this actually raises a potential issue: we really should have > separate back-pressure on each fd, so that failure to consume data from > a particular fd does not wedge the whole channel. I would say that this is the biggest issue of all, and should be carefully considered before even _starting_ to write the detailed spec and nail down things like the names and formats of new channel requests. What are the pros and cons of folding multiple (fd,direction) pairs into a single window? Why did we ever invent CHANNEL_EXTENDED_DATA for stderr at all, instead of setting up two channels with separate windows and linking them together somehow? Only by understanding that question can we get a clear idea of whether we should extend the mechanism for further fds or instead use separate channels. As far as I can see, the key advantage of CHANNEL_EXTENDED_DATA is that it allows the recipient to preserve the same interleaving of the stdout and stderr data, in the case where this is perceptible (because the SSH client's stdout and stderr fds are duplicates of each other, i.e. target the _same_ terminal device or pipe or file). However, in practice, this is of limited use to a server on a POSIXlike platform, because it in turn can't know what the right interleaving of stdout and stderr was from the point of view of the application doing the writing. It can only select() between the output and error channels, and when data becomes available on both at once it can't know precisely what sequence of writes was intended. Of course if _it_ folds stdout and stderr into the same fd (as it does when allocating a pty) then interleaving is perfect - but then you don't get CHANNEL_EXTENDED_DATA at all. So it seems to me that the real added value of CHANNEL_EXTENDED_DATA is only realised in cases where the server diverges from POSIX in some way. Therefore, a consciously POSIX-oriented extension to handle multiple fds ought not to be perpetuating the use of the mechanism. (A year or two ago I wrote an application which tried to forward an arbitrary set of file descriptors across a serialisation boundary in a completely different context from SSH, and what I actually did was to have the client _work out_ which of its fds were duplicates of each other and then pass that information to the server. So the server would allocate a single pipe on its side for both stdout and stderr, if and only if the client had not redirected them to different places. Thus, stdout and stderr output were interleaved exactly as the application intended in cases where you could tell the difference, and separated correctly otherwise.) Cheers, Simon -- Simon Tatham "I'm going to pull his head off. Ear by ear." - a games teacher From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 10:55:48 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5483A686B for ; Wed, 25 Aug 2010 10:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRcyxOQRb6Xz for ; Wed, 25 Aug 2010 10:55:48 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id BBE2E3A6805 for ; Wed, 25 Aug 2010 10:55:47 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 1A0A7715EA for ; Wed, 25 Aug 2010 17:56:20 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 7089E63B130; Wed, 25 Aug 2010 17:54:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 7061563B108 for ; Wed, 25 Aug 2010 17:54:18 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA21489; Wed, 25 Aug 2010 13:54:17 -0400 (EDT) Date: Wed, 25 Aug 2010 13:54:17 -0400 (EDT) From: der Mouse Message-Id: <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 11:48:54 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: <20100825154113.GT17097@oracle.com> References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <20100825154113.GT17097@oracle.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Here's what I have. Comments are invited. > I like the idea, though I'd like to see how it'd be used from a > typical Unix command-line. I'm guessing something like a CLI option > to list file descripto numbers to forward, something like > "ssh -r 0,1,2,5,7 ..." Yes, though (because forwarding can go either way) you also need to specify whether each fd is to be input, output, or both. (Or neither, I suppose, if-and-when anyone comes up with a use for that.) I haven't really thought much about the command-line interface. That's an implementation-specific aspect (some implementations don't really have a command line in the traditional sense, for example), and at this point I've been thinking more about the protocol aspects. I'd probably do something like ssh -fd-in 3,4 -fd-out 7 -fd-both 10,12,13 ... but this is totally up to each implementation to decide (for those that choose to implement it at all, of course). >> As a global request, [...] > Why is a global request needed? It's not really _needed_. It is designed to allow the client to probe for the presence of support earlier than the channel request does. (I should have stated this; I'll fix that.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 11:54:31 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573BC3A6888 for ; Wed, 25 Aug 2010 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-QEBgwXkcjW for ; Wed, 25 Aug 2010 11:54:30 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 29B813A687F for ; Wed, 25 Aug 2010 11:54:30 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 84A6271605 for ; Wed, 25 Aug 2010 18:55:02 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id A4EDB63B100; Wed, 25 Aug 2010 18:54:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 2643C63B109 for ; Wed, 25 Aug 2010 18:54:44 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA21797; Wed, 25 Aug 2010 14:54:43 -0400 (EDT) Date: Wed, 25 Aug 2010 14:54:43 -0400 (EDT) From: der Mouse Message-Id: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 14:00:27 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Hm, this actually raises a potential issue: we really should have >> separate back-pressure on each fd, so that failure to consume data >> from a particular fd does not wedge the whole channel. > I would say that this is the biggest issue of all, and should be > carefully considered before even _starting_ to write the detailed > spec and nail down things like the names and formats of new channel > requests. I am inclined to agree. If I'd thought of the back-pressure issue before I'd written up the rest of it, I would have - but I didn't think of that until this conversation. > What are the pros and cons of folding multiple (fd,direction) pairs > into a single window? Why did we ever invent CHANNEL_EXTENDED_DATA > for stderr at all, instead of setting up two channels with separate > windows and linking them together somehow? Good question. I don't recall hearing; I certainly wasn't the person who made that choice. :-) > As far as I can see, the key advantage of CHANNEL_EXTENDED_DATA is > that it allows the recipient to preserve the same interleaving of the > stdout and stderr data, in the case where this is perceptible > (because the SSH client's stdout and stderr fds are duplicates of > each other, i.e. target the _same_ terminal device or pipe or file). After a fashion. As you point out, this isn't really possible with the currently-widespread interfaces between sshd and the process being run. While, as I said, I wasn't around when the decision was made, I suspect that what happened is something like "oh, we want something separate for stderr; let's throw in an alternative data mechanism", with the implications not really thought through - in particular, the effects on the data window and channel EOF not being given much thought. For that matter, while I thought of the EOF issues, I didn't think of the window issues until this conversation.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 14:39:14 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32163A68D8 for ; Wed, 25 Aug 2010 14:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za7FJZnsKY90 for ; Wed, 25 Aug 2010 14:38:49 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 38F933A6B4F for ; Wed, 25 Aug 2010 14:37:17 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 517B57144A for ; Wed, 25 Aug 2010 21:37:41 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 380C063B104; Wed, 25 Aug 2010 21:37:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 7DCE363B101 for ; Wed, 25 Aug 2010 21:37:14 +0000 (UTC) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PLbCDS009735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 21:37:13 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7PLb9KX008523; Wed, 25 Aug 2010 21:37:10 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 549247871282772180; Wed, 25 Aug 2010 14:36:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 14:36:20 -0700 Date: Wed, 25 Aug 2010 16:36:15 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 Message-ID: <20100825213615.GE17097@oracle.com> References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <20100825154113.GT17097@oracle.com> <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 25, 2010 at 01:54:17PM -0400, der Mouse wrote: > >> As a global request, [...] > > Why is a global request needed? > > It's not really _needed_. It is designed to allow the client to probe > for the presence of support earlier than the channel request does. (I > should have stated this; I'll fix that.) I thought so. But it can be very simple then. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 14:49:22 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E2B3A6942 for ; Wed, 25 Aug 2010 14:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdpgOLQ7uMZw for ; Wed, 25 Aug 2010 14:49:21 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 9A4B13A6837 for ; Wed, 25 Aug 2010 14:49:20 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 97DFF706B6 for ; Wed, 25 Aug 2010 21:49:52 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 32E8863B101; Wed, 25 Aug 2010 21:49:39 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 8236263B100 for ; Wed, 25 Aug 2010 21:49:37 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PLnYAW031706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 21:49:35 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7PK9dAk013321; Wed, 25 Aug 2010 21:49:33 GMT Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 549280581282772916; Wed, 25 Aug 2010 14:48:36 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 14:48:36 -0700 Date: Wed, 25 Aug 2010 16:48:31 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 Message-ID: <20100825214830.GF17097@oracle.com> References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 25, 2010 at 02:54:43PM -0400, der Mouse wrote: > On Wed, 25 Aug 2010 17:27:22 +0100, Simon Tatham wrote: > >> Hm, this actually raises a potential issue: we really should have > >> separate back-pressure on each fd, so that failure to consume data > >> from a particular fd does not wedge the whole channel. > > > > I would say that this is the biggest issue of all, and should be > > carefully considered before even _starting_ to write the detailed > > spec and nail down things like the names and formats of new channel > > requests. > > I am inclined to agree. If I'd thought of the back-pressure issue > before I'd written up the rest of it, I would have - but I didn't think > of that until this conversation. I think each FD should have its own flow-control. Just as it works in any Unix/POSIX OS. The current channel design has two flows in each direction (data and "extended" data), with just one flow control window in each direction. That's... weird. It works, I guess, but it strikes me as a poor design. > > What are the pros and cons of folding multiple (fd,direction) pairs > > into a single window? Why did we ever invent CHANNEL_EXTENDED_DATA > > for stderr at all, instead of setting up two channels with separate > > windows and linking them together somehow? > > Good question. I don't recall hearing; I certainly wasn't the person > who made that choice. :-) I've always wondered myself. Heck, we could have had a channel for each direction, such that we'd have needed _three_ linked channels for a shell session. My guess is that SSHv1 design and simplicity informed the v2 channel design. Or, as der Mouse thinks, maybe it was an [ill] afterthought. The more "extended" data flows we add, the more likely it is that we'll have a problem with the single window for all flows in one direction issue, though I'm not sure how severe any problems will be. > > As far as I can see, the key advantage of CHANNEL_EXTENDED_DATA is > > that it allows the recipient to preserve the same interleaving of the > > stdout and stderr data, in the case where this is perceptible > > (because the SSH client's stdout and stderr fds are duplicates of > > each other, i.e. target the _same_ terminal device or pipe or file). That's true in the pty case (because the stdout/stderr distinction is lost before the writes even happen as the two fildes will both refer to the same pty). It's not necessarily true in the no-pty case. If the server uses two distinct pipes for stdout and stderr then the relative ordering of stdout/stderr writes will be lost. It's the no-pty case where the distinction between stdout and stderr becomes useful! (Because the client can do redirection of the two separately on the client side.) > After a fashion. As you point out, this isn't really possible with the > currently-widespread interfaces between sshd and the process being run. Right. > While, as I said, I wasn't around when the decision was made, I suspect > that what happened is something like "oh, we want something separate > for stderr; let's throw in an alternative data mechanism", with the > implications not really thought through - in particular, the effects on > the data window and channel EOF not being given much thought. For that > matter, while I thought of the EOF issues, I didn't think of the window > issues until this conversation.... Yeah, it seems like an afterthought. Do you really need the multiple fd thing? Sounds like you might need to do some violence to the connection protocol... Well, maybe not so much violence, just a way to link channels. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 15:12:07 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93C73A68B8 for ; Wed, 25 Aug 2010 15:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtadvBOUDzcm for ; Wed, 25 Aug 2010 15:12:06 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 777E03A63C9 for ; Wed, 25 Aug 2010 15:12:05 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id A5D5171631 for ; Wed, 25 Aug 2010 22:12:37 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 8E31D63B101; Wed, 25 Aug 2010 22:12:24 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3CE7263B100 for ; Wed, 25 Aug 2010 22:12:22 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1OoOCi-0004xh-Lq; Wed, 25 Aug 2010 23:12:20 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20100825214830.GF17097@oracle.com> Subject: Re: fds beyond 0/1/2 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 25 Aug 2010 23:12:20 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams wrote: > That's true in the pty case (because the stdout/stderr distinction is > lost before the writes even happen as the two fildes will both refer to > the same pty). > > It's not necessarily true in the no-pty case. If the server uses two > distinct pipes for stdout and stderr then the relative ordering of > stdout/stderr writes will be lost. Indeed, as I said in my next paragraph. But if the server is running on some entirely different mechanism which does permit distinguished stdout and stderr data to be transferred from the server-side application keeping both interleaving and identification, then the CHANNEL_EXTENDED_DATA system can preserve that as far as the client. An obvious example of such a server-side application would be one that's _part_ of the SSH server process and is explicitly constructing channel data packets! Some dedicated kind of server - perhaps one running on a router or other embedded-class device - is easy to imagine doing such a thing, and if it did, it could extract some actual value from the EXTENDED_DATA mechanism. But, as I also said, this is irrelevant to the POSIX world and should be considered an amusing sidetrack only for these purposes. > Do you really need the multiple fd thing? Sounds like you might need to > do some violence to the connection protocol... Well, maybe not so much > violence, just a way to link channels. Yes. I think a basically sensible approach would be to simply introduce a new class of channel, whose CHANNEL_OPEN message cites (alongside all the normal stuff) the remote id of a "session" channel currently in its setup phase, and indicates a file descriptor (with optional direction) to be opened in the session channel's process when it's launched. So you'd set up a few of those, then kick off your shell or subsystem or whatever, and you've got all the separate windows and EOF statuses you need. (Perhaps it should also be legal to cite fd 2 in such a message, in which case the server would never send CHANNEL_EXTENDED_DATA on the session channel, and stderr would come down the auxiliary channel instead.) Cheers, Simon -- Simon Tatham "_shin_, n. An ingenious device for finding tables and chairs in the dark." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 15:30:45 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0A33A6835 for ; Wed, 25 Aug 2010 15:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixq16+TS+G+n for ; Wed, 25 Aug 2010 15:30:40 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id B0F4E3A63C9 for ; Wed, 25 Aug 2010 15:30:39 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id F1DD8708B5 for ; Wed, 25 Aug 2010 22:31:11 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 56D7763B104; Wed, 25 Aug 2010 22:30:57 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id C12AB63B101 for ; Wed, 25 Aug 2010 22:30:55 +0000 (UTC) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PMUkWe014843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 22:30:48 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7PHiSZH025782; Wed, 25 Aug 2010 22:30:46 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 549366401282775414; Wed, 25 Aug 2010 15:30:14 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 15:30:14 -0700 Date: Wed, 25 Aug 2010 17:30:09 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 Message-ID: <20100825223009.GJ17097@oracle.com> References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> <50BB113545133E3FD38ADBA6@lysithea.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50BB113545133E3FD38ADBA6@lysithea.fac.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 25, 2010 at 06:13:44PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, August 25, 2010 04:48:31 PM -0500 Nicolas Williams > wrote: > > >That's true in the pty case (because the stdout/stderr distinction is > >lost before the writes even happen as the two fildes will both refer to > >the same pty). > > > >It's not necessarily true in the no-pty case. If the server uses two > >distinct pipes for stdout and stderr then the relative ordering of > >stdout/stderr writes will be lost. > > But it's _already_ been lost, because there is no guarantee that the > server will see those pipes become readable in the order in which > the app wrote to them; they may even become readable at the same > time. [...] There was never any way to preserve the interleave order of stdout/stderr writes because if they are the same pipe/whatever then the order is lost immediately, and if they are not then the order is lost... immediately. But I agreed already (maybe the "That's true in the pty case / not necessarily true in the no-pty case" bit was confusing). I think we're just in agreement :) > The only way to preserve relative ordering of stdout/stderr for the > server to send them in the right order is for the server and app to > have a communication channel that is already interleaved, either > through something more complex than a pair of pipes or because > they've already been combined into a single stream, as in the pty > case. No such thing exists in Unix/POSIX systems. Attempting to preserve stdout/stderr relative ordering was always a mistake. But I don't know that that was ever the goal. My guess is the goal was to allow I/O redirection for stdout/stderr separately on the client side, and the "extended" data thing was just a hack. Using a separate "linked" channel would have prompted one to wonder why have bidirectional channels at all, which might have opened a can of worms. OTOH, thinking about this now, I suspect linked one-directional channels could actually simplify the implementations. > >Do you really need the multiple fd thing? > > It seems like it would be useful. I've certainly encountered > situations where it was useful to connect multiple fds between > processes running on the same machine, and what is ssh if not a way > to start and communicate with processes running on some other > machine? Complex shell scripting scenarios come to mind, yes. > >Sounds like you might need to > >do some violence to the connection protocol... Well, maybe not so much > >violence, just a way to link channels. > > I don't think it'd be too bad. I can think of three ways to do this: Sure. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 15:49:15 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8636E3A694C for ; Wed, 25 Aug 2010 15:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuhsAOD7OG4F for ; Wed, 25 Aug 2010 15:49:14 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 1ABB93A6926 for ; Wed, 25 Aug 2010 15:49:14 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 3A8AA70680 for ; Wed, 25 Aug 2010 22:49:46 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 45B4163B100; Wed, 25 Aug 2010 22:49:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "USERTrust Legacy Secure Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 87C7B63B108 for ; Wed, 25 Aug 2010 22:49:28 +0000 (UTC) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o7PMDix8022032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 18:13:44 -0400 (EDT) Date: Wed, 25 Aug 2010 18:13:44 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , der Mouse cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: fds beyond 0/1/2 Message-ID: <50BB113545133E3FD38ADBA6@lysithea.fac.cs.cmu.edu> In-Reply-To: <20100825214830.GF17097@oracle.com> References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, August 25, 2010 04:48:31 PM -0500 Nicolas Williams wrote: > That's true in the pty case (because the stdout/stderr distinction is > lost before the writes even happen as the two fildes will both refer to > the same pty). > > It's not necessarily true in the no-pty case. If the server uses two > distinct pipes for stdout and stderr then the relative ordering of > stdout/stderr writes will be lost. But it's _already_ been lost, because there is no guarantee that the server will see those pipes become readable in the order in which the app wrote to them; they may even become readable at the same time. The app may write to stdout, then stderr, then stdout again before the server has read the first bit of stdout, so it doesn't even know there was an interleave, let alone where it is. The only way to preserve relative ordering of stdout/stderr for the server to send them in the right order is for the server and app to have a communication channel that is already interleaved, either through something more complex than a pair of pipes or because they've already been combined into a single stream, as in the pty case. > Do you really need the multiple fd thing? It seems like it would be useful. I've certainly encountered situations where it was useful to connect multiple fds between processes running on the same machine, and what is ssh if not a way to start and communicate with processes running on some other machine? > Sounds like you might need to > do some violence to the connection protocol... Well, maybe not so much > violence, just a way to link channels. I don't think it'd be too bad. I can think of three ways to do this: 1) A channel request on the session channel that results in creation of a new channel a la SSH_MSG_CHANNEL_OPEN. I don't recommend this; it's a horrible abstraction violation and basically requires repeating all of the previously common bits of channel setup in a new place. That'll get particularly annoying if we ever add a new variation on SSH_MSG_CHANNEL_OPEN. 2) A new "fd" channel type, whose type-specific channel request data includes the channel number of the existing session channel, the remote fd number, and the direction information. 3) A new generic "pipe" channel type, which establishes a channel but doesn't bind it to anything, combined with a new "dup2" channel request on the session channel that specifies the remote fd number, direction information, and the existing channel to connect the fd to. The existing channel would have to be one of - an unused pipe channel - a pipe channel already attached to this session - the session channel Note that this allows you to attach multiple fds to the same channel, including the main session channel. One could even use this to set up a "normal" session with separate flow control for stdout and stderr. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 15:49:39 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E403A6926 for ; Wed, 25 Aug 2010 15:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygsA6xQnTcyi for ; Wed, 25 Aug 2010 15:49:38 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 87C2B3A689B for ; Wed, 25 Aug 2010 15:49:38 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id BF6D27162C for ; Wed, 25 Aug 2010 22:50:10 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 127C663B108; Wed, 25 Aug 2010 22:49:38 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "USERTrust Legacy Secure Server CA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 4CF2B63B101 for ; Wed, 25 Aug 2010 22:49:29 +0000 (UTC) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o7PLhdCa021737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 17:43:39 -0400 (EDT) Date: Wed, 25 Aug 2010 17:43:39 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: fds beyond 0/1/2 Message-ID: In-Reply-To: <201008251519.LAA20817@Sparkle.Rodents-Montreal.ORG> References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251519.LAA20817@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, August 25, 2010 11:19:29 AM -0400 der Mouse wrote: >> All fd:s of the channel would then use a single window (or rather, >> one in each direction) for flow control. > > Right. > >> I take it this could be useful for both directions, although with the >> client in chanrge of setting everything up. > > Yes. So far it seems your thoughts and mine are tracking pretty > closely, so I'm probably not totally off in the weeds. > > Hm, this actually raises a potential issue: we really should have > separate back-pressure on each fd, so that failure to consume data from > a particular fd does not wedge the whole channel. The way to do that is to use a separate channel, so that you get separate flow control, which is what you need to insure this. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 18:20:08 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E25F3A6A94 for ; Wed, 25 Aug 2010 18:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdmCX34Txw7A for ; Wed, 25 Aug 2010 18:20:06 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 54E203A68C3 for ; Wed, 25 Aug 2010 18:20:05 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 44B2270AF3 for ; Thu, 26 Aug 2010 01:20:37 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 7F2A763B101; Thu, 26 Aug 2010 01:20:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 0A4C563B100 for ; Thu, 26 Aug 2010 01:20:18 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA23522; Wed, 25 Aug 2010 21:20:18 -0400 (EDT) Date: Wed, 25 Aug 2010 21:20:18 -0400 (EDT) From: der Mouse Message-Id: <201008260120.VAA23522@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 21:17:39 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: <20100825213615.GE17097@oracle.com> References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <20100825154113.GT17097@oracle.com> <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> <20100825213615.GE17097@oracle.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>>> As a global request, [...] >>> Why is a global request needed? >> It's not really _needed_. It is designed to allow the client to >> probe for the presence of support earlier than the channel request >> does. > I thought so. But it can be very simple then. It can. It is. Describing it takes one whole paragraph. I'm not sure it will survive the flow-control-driven changes, though. The flow control issue means the scheme I concocted is probably pretty much useless in the form I described; see the rest of this thread. :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 19:03:36 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3823A6966 for ; Wed, 25 Aug 2010 19:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eoN2jynXSdF for ; Wed, 25 Aug 2010 19:03:35 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id E4DC73A6900 for ; Wed, 25 Aug 2010 19:03:34 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id C2CB170AF4 for ; Thu, 26 Aug 2010 02:04:06 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id C237963B101; Thu, 26 Aug 2010 02:03:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 11B0563B100 for ; Thu, 26 Aug 2010 02:03:50 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id WAA23705; Wed, 25 Aug 2010 22:03:50 -0400 (EDT) Date: Wed, 25 Aug 2010 22:03:50 -0400 (EDT) From: der Mouse Message-Id: <201008260203.WAA23705@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Wed, 25 Aug 2010 21:20:54 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: <20100825214830.GF17097@oracle.com> References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Replying to multiple messages, here.... [Nicolas.Williams@oracle.com] > The current channel design has two flows in each direction (data and > "extended" data), with just one flow control window in each > direction. No, it has 4294967297 potential flows in each direction (data, and an int32 worth of different extended data flows). It has three standardized data flows (one from the client to server and two from the server to the client) and up to 67108864 nonstandardized flows (33554432 each way), plus possible future standardization (or even past standardization for all I know, though I would have expected any such to go by on this list). All this is per channel, of course. And all the flows in a given direction for a given channel share the same flow-control window. Fine for some purposes. Not a good fit to the generic Unixish model. Tolerable in the input direction because so far there's only the one flow. Tolerable in the output direction largely because there are few-to-no programs that depend on stderr getting through when stdout is blocked by back-pressure (and even fewer that do the same with stderr and stdout switched). But add arbitrary fd forwarding and it all starts to fall apart. > The more "extended" data flows we add, the more likely it is that > we'll have a problem with the single window for all flows in one > direction issue, though I'm not sure how severe any problems will be. Agreed. > Do you really need the multiple fd thing? Need? Arguably not. But then, I arguably don't really _need_ ssh at all. Or even computers - it all depends on where you draw the line between "need" and "want". Let me put it thus: arbitrary fd forwarding is valuable enough to me for me to put nontrivial amounts of time into designing a mechanism to support it and implementing it in moussh. [anakin@pobox.com] > I think a basically sensible approach would be to simply introduce a > new class of channel, whose CHANNEL_OPEN message cites (alongside all > the normal stuff) the remote id of a "session" channel [...] [jhutz@cmu.edu] > I can think of three ways to do this: > 1) A channel request on the session channel that results in creation > of a new channel a la SSH_MSG_CHANNEL_OPEN. > 2) A new "fd" channel type, [basically anakin@'s idea above] > 3) A new generic "pipe" channel type, [generalization of (2)] There's another way, which nobody seems to have mentioned yet. I'm not sure where it fits into my preference list with respect to the others. It is simple to state: give each data flow within a channel its own flow-control window. I can think of some pros and cons, some of which depend on the details. I'm sure most of you people can too. I'd probably go with two completely new window-adjust messages, one for CHANNEL_DATA data and another, with a data_type_code, for CHANNEL_EXTENDED_DATA data. I can imagine various possible ways to handle using this mechanism instead of the shared window; my inclination after only a few seconds of thinking is to make it a global request, which, if accepted, causes all data on the connection which carried the global request to use per-flow windows (use of standard window adjustments after issuing or accepting the global request would be a protocol error). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Aug 25 23:18:18 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051893A6A87 for ; Wed, 25 Aug 2010 23:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0wy77sAh4ts for ; Wed, 25 Aug 2010 23:18:17 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id A09063A6403 for ; Wed, 25 Aug 2010 23:18:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id EF33A7161E for ; Thu, 26 Aug 2010 06:18:48 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4F02563B104; Thu, 26 Aug 2010 06:18:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "rcsinet10.oracle.com", Issuer "VeriSign Trust Network" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 6412B63B100 for ; Thu, 26 Aug 2010 06:18:14 +0000 (UTC) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7Q6IBT5020438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Aug 2010 06:18:13 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7Q6IB1L022752; Thu, 26 Aug 2010 06:18:11 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 533043631282803398; Wed, 25 Aug 2010 23:16:38 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 23:16:37 -0700 Date: Thu, 26 Aug 2010 01:16:33 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 Message-ID: <20100826061632.GO17097@oracle.com> References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> <201008260203.WAA23705@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008260203.WAA23705@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2010-03-02) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Aug 25, 2010 at 10:03:50PM -0400, der Mouse wrote: > Replying to multiple messages, here.... > > [Nicolas.Williams@oracle.com] > > The current channel design has two flows in each direction (data and > > "extended" data), with just one flow control window in each > > direction. > > No, it has 4294967297 potential flows in each direction (data, and an > ... Sure, sure. A funny nit :) > Fine for some purposes. Not a good fit to the generic Unixish model. Indeed. > > Do you really need the multiple fd thing? > > Need? Arguably not. But then, I arguably don't really _need_ ssh at > all. Or even computers - it all depends on where you draw the line > between "need" and "want". Let me put it thus: arbitrary fd forwarding > is valuable enough to me for me to put nontrivial amounts of time into > designing a mechanism to support it and implementing it in moussh. If you implement, then that's good enough for me. Write up an I-D. > [jhutz@cmu.edu] > > I can think of three ways to do this: > > There's another way, which nobody seems to have mentioned yet. I'm not > sure where it fits into my preference list with respect to the others. > > It is simple to state: give each data flow within a channel its own > flow-control window. > > I can think of some pros and cons, some of which depend on the details. > I'm sure most of you people can too. I'd probably go with two > completely new window-adjust messages, one for CHANNEL_DATA data and > another, with a data_type_code, for CHANNEL_EXTENDED_DATA data. I can > imagine various possible ways to handle using this mechanism instead of > the shared window; my inclination after only a few seconds of thinking > is to make it a global request, which, if accepted, causes all data on > the connection which carried the global request to use per-flow > windows (use of standard window adjustments after issuing or accepting > the global request would be a protocol error). That will do too. In retrospect I wish the connection protocol had always just had linkable uni-directional channels (with a way to create channel pairs in one go, for things like port forwarding). I suspect the channel state machines would have been much simpler that way! But, it's too late :( Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 00:37:58 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFFF3A6A72 for ; Thu, 26 Aug 2010 00:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7Jzsc4rPCuQ for ; Thu, 26 Aug 2010 00:37:49 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 140933A679F for ; Thu, 26 Aug 2010 00:37:49 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 59A55708EF for ; Thu, 26 Aug 2010 07:38:21 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id A026A63B100; Thu, 26 Aug 2010 07:38:08 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3E6B963B104 for ; Thu, 26 Aug 2010 07:38:06 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 91661C4B05; Thu, 26 Aug 2010 17:38:04 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id D6AF7C4AA8; Thu, 26 Aug 2010 17:37:59 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 8548F3FA46; Thu, 26 Aug 2010 17:37:59 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 836273F9AA; Thu, 26 Aug 2010 17:37:59 +1000 (EST) Date: Thu, 26 Aug 2010 17:37:59 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 25 Aug 2010, der Mouse wrote: (responding to this part until I digest the rest of the proposal) > ---------------- data-eof@rodents.montreal.qc.ca > > Standard ssh has no way to indicate EOF on one data flow without > indicating EOF on the entire channel. For input, this is not a > problem, since there is only one data flow, but it is an issue for > output, and, if any input fds are forwarded with fd-forward, it can be > a problem for input too. We deal with this issue with data-eof channel > requests. OpenSSH has had a eow@openssh.com SSH_MSG_CHANNEL_REQUEST to indicate the missing half-close state for a while. Unfortunately, it turns out that quite a few SSH implementations barf when they see extension channel requests that they don't recognise, so we turned it off for implementations that don't identify themselves as OpenSSH. So much for an extensible protocol... The documentation for this (and other OpenSSH extensions) is at: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 03:48:55 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5651D3A681D for ; Thu, 26 Aug 2010 03:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-UYpFfYfEqO for ; Thu, 26 Aug 2010 03:48:47 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 4CFA73A6828 for ; Thu, 26 Aug 2010 03:48:47 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 5DD757161E for ; Thu, 26 Aug 2010 10:49:19 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 7C2CC63B101; Thu, 26 Aug 2010 10:49:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id E45CC63B100 for ; Thu, 26 Aug 2010 10:49:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id GAA26070; Thu, 26 Aug 2010 06:49:03 -0400 (EDT) Date: Thu, 26 Aug 2010 06:49:03 -0400 (EDT) From: der Mouse Message-Id: <201008261049.GAA26070@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 26 Aug 2010 06:11:54 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Standard ssh has no way to indicate EOF on one data flow without >> indicating EOF on the entire channel. [...] > OpenSSH has had a eow@openssh.com SSH_MSG_CHANNEL_REQUEST to indicate > the missing half-close state for a while. According to the PROTOCOL document you (later) pointed me at (and thank you, I've been wanting such a thing for a while), eow@openssh.com does not do what my data-eof@rodents.montreal.qc.ca request does. Rather, eow@openssh.com pushes back what I might loosely call SIGPIPE/EPIPE status, ie, "don't write more to me", and does it for the whole channel. data-eof@ is for signaling "I am not going to write anything more", ie, a traditional EOF. The difference between it and SSH_MSG_CHANNEL_EOF is that data-eof@ is for one data flow, not for the whole channel. (If there's only one flow in use in that direction on the channel, it is functionally equivalent to SSH_MSG_CHANNEL_EOF.) Of course, depending on what ends up happening with the flow-control discussion, it's possible the use of more than one flow per channel will pretty much die except for legacy stdout/stderr use, in which case data-eof@ will become correspondingly pointless. > The documentation for this (and other OpenSSH extensions) is at: > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD That file does not, amusingly enough, seem to include the one @openssh.com extension I saw in the wild and went looking for documentation on, keepalive@openssh.com. > Unfortunately, it turns out that quite a few SSH implementations barf > when they see extension channel requests that they don't recognise, Heh. While it currently won't actually offer any functionality (I don't yet implement any of your extensions), it should be safe to send such things to moussh; it shouldn't fall over because of a channel request it doesn't understand - and if it does I consider that a critical bug. Not that it really matters, I suppose; you're not likely to see moussh in the wild very much - I haven't even heard of, much less heard from, anyone besides me who uses it routinely. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 04:54:47 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0863A6838 for ; Thu, 26 Aug 2010 04:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Y5osdsOJ0q for ; Thu, 26 Aug 2010 04:54:39 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 9B03D3A6A97 for ; Thu, 26 Aug 2010 04:54:38 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 59DE771625 for ; Thu, 26 Aug 2010 11:55:10 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id E5A4A63B108; Thu, 26 Aug 2010 11:54:19 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9882163B100 for ; Thu, 26 Aug 2010 11:54:15 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 03C5AC4B52; Thu, 26 Aug 2010 21:54:12 +1000 (EST) Received: from fuyu.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 Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id A324CC4AA8; Thu, 26 Aug 2010 21:54:07 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 4E425400BC; Thu, 26 Aug 2010 21:54:07 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 49B193FA07; Thu, 26 Aug 2010 21:54:07 +1000 (EST) Date: Thu, 26 Aug 2010 21:54:07 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: <201008261049.GAA26070@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <201008261049.GAA26070@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 26 Aug 2010, der Mouse wrote: > According to the PROTOCOL document you (later) pointed me at (and thank > you, I've been wanting such a thing for a while), eow@openssh.com does > not do what my data-eof@rodents.montreal.qc.ca request does. Rather, > eow@openssh.com pushes back what I might loosely call SIGPIPE/EPIPE > status, ie, "don't write more to me", and does it for the whole > channel. > > data-eof@ is for signaling "I am not going to write anything more", ie, > a traditional EOF. The difference between it and SSH_MSG_CHANNEL_EOF > is that data-eof@ is for one data flow, not for the whole channel. (If > there's only one flow in use in that direction on the channel, it is > functionally equivalent to SSH_MSG_CHANNEL_EOF.) I'm not sure I follow; SSH_MSG_CHANNEL_EOF doesn't shut down data bidirectionally. From rfc4254: > 5.3. Closing a Channel > > When a party will no longer send more data to a channel, it SHOULD > send SSH_MSG_CHANNEL_EOF. > > byte SSH_MSG_CHANNEL_EOF > uint32 recipient channel > > No explicit response is sent to this message. However, the > application may send EOF to whatever is at the other end of the > channel. Note that the channel remains open after this message, and > more data may still be sent in the other direction. This message > does not consume window space and can be sent even if no window space > is available. though it does not allow signalling of closure of the extended-data subchannel - is this what you are talking about? > > The documentation for this (and other OpenSSH extensions) is at: > > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD > > That file does not, amusingly enough, seem to include the one > @openssh.com extension I saw in the wild and went looking for > documentation on, keepalive@openssh.com. that's because youd don't have to actually implement it, just follow the spec and return SSH_MSG_UNIMPLEMENTED/SSH_MSG_CHANNEL_FAILURE -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 05:33:34 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA853A68B9 for ; Thu, 26 Aug 2010 05:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epQXSv4JDHiv for ; Thu, 26 Aug 2010 05:33:31 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id E73FF3A6986 for ; Thu, 26 Aug 2010 05:33:30 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id B07707165B for ; Thu, 26 Aug 2010 12:34:02 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 8183E63B101; Thu, 26 Aug 2010 12:33:47 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 1984963B100 for ; Thu, 26 Aug 2010 12:33:45 +0000 (UTC) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o7QCXe9U027134; Thu, 26 Aug 2010 14:33:40 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o7QCXeVm027133; Thu, 26 Aug 2010 14:33:40 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Nicolas Williams Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> Date: Thu, 26 Aug 2010 14:33:40 +0200 In-Reply-To: <20100825214830.GF17097@oracle.com> (Nicolas Williams's message of "Wed, 25 Aug 2010 16:48:31 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Nicolas Williams writes: > That's true in the pty case (because the stdout/stderr distinction is > lost before the writes even happen as the two fildes will both refer to > the same pty). It's possible (and perfectly logical, at least to me) to implement the pty case on the server side by allocating one pty to use for stdin and stdout, and a separate pipe for stderr. But when I tried thet, some shells, notably bash, seemed to get into problems. Anyway, I don't see a big problem with having the same flow control window for stdout and stderr. Not sure what to think about the multiple fd case, since it's unclear to me what the applications are. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 05:54:14 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4443A6AC0 for ; Thu, 26 Aug 2010 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn7MAqB5PCGm for ; Thu, 26 Aug 2010 05:54:13 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 24EA53A67E2 for ; Thu, 26 Aug 2010 05:54:13 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 641467167C for ; Thu, 26 Aug 2010 12:54:45 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 4547663B109; Thu, 26 Aug 2010 12:54:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id B9CC763B104 for ; Thu, 26 Aug 2010 12:54:28 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA26658; Thu, 26 Aug 2010 08:54:27 -0400 (EDT) Date: Thu, 26 Aug 2010 08:54:27 -0400 (EDT) From: der Mouse Message-Id: <201008261254.IAA26658@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 26 Aug 2010 08:38:17 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <201008261049.GAA26070@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> [...] eow@openssh.com [...] data-eof@rodents.montreal.qc.ca [...] > I'm not sure I follow; SSH_MSG_CHANNEL_EOF doesn't shut down data > bidirectionally. No; it shuts it down in the same direction my data-eof@ does. But CHANNEL_EOF shuts down the entire channel. My data-eof@ shuts down just one data flow. If there is only the one data flow (as is the case for client->server data in the standard protocol), there is no functional difference, but if there's more than one (as is the case for server->client, or with forwarded fds if they end up being flows within the main channel), data-eof@ can shut down one without affecting others, which CHANNEL_EOF can't. Yes, there is a need for shutdown capability in the other direction, the direction eow@ does - but it too arguably should be per-flow rather than whole-channel. >> That file does not, amusingly enough, seem to include the one >> @openssh.com extension I saw in the wild and went looking for >> documentation on, keepalive@openssh.com. > that's because youd don't have to actually implement it, just follow > the spec and return SSH_MSG_UNIMPLEMENTED/SSH_MSG_CHANNEL_FAILURE Well, it would have been reassuring to find a spec saying so. :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 06:24:20 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B00A3A6908 for ; Thu, 26 Aug 2010 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT5qS2AeIOX7 for ; Thu, 26 Aug 2010 06:24:19 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 583BD3A67E2 for ; Thu, 26 Aug 2010 06:24:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 8D1B27169A for ; Thu, 26 Aug 2010 13:24:51 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id B3F7663B101; Thu, 26 Aug 2010 13:24:36 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 37B2B63B100 for ; Thu, 26 Aug 2010 13:24:35 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA26794; Thu, 26 Aug 2010 09:24:34 -0400 (EDT) Date: Thu, 26 Aug 2010 09:24:34 -0400 (EDT) From: der Mouse Message-Id: <201008261324.JAA26794@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 26 Aug 2010 08:54:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251854.OAA21797@Sparkle.Rodents-Montreal.ORG> <20100825214830.GF17097@oracle.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Anyway, I don't see a big problem with having the same flow control > window for stdout and stderr. Neither do I, but that's because of how they're used, not because there's no problem in principle. There are few-to-no programs that depend on stderr getting through even when stdout is blocked by back-pressure, and even fewer that depend on stdout working when stderr is blocked by back-pressure. > Not sure what to think about the multiple fd case, since it's unclear > to me what the applications are. Well, I certainly want it. Some of the applications I have for it would break if one flow's blocking wedged other flows in the same direction. To pick a simple example (so simple that it probably would not be done in practice, but it illustrates the risk): cat file1 | (exec 3<&0; cat file2 | ssh -fd-in 3 remote cmp - /dev/fd/3) Now, let us suppose that cmp works like while (there's data available) { read from file A read from file B compare } Now suppose that "cat file1" runs first, and fills up pipes and eventually blocks on back-pressure. cmp is then sitting there trying to read "cat file2"'s output, but it can't, because ssh can't send it because there's no window space. If the producer programs are more complex than cat, this sort of timing is not at all implausible - all that's required is that one program produce enough output to block while the other produces nothing. In the case of cmp, I probably wouldn't bother running it remotely, but it could be any consumer; all that's needed is that it be unwilling to buffer arbitrarily large amounts of output from the fast producer while waiting for output from the slow producer. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 06:36:06 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BB03A6974 for ; Thu, 26 Aug 2010 06:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfqb4d5d79C8 for ; Thu, 26 Aug 2010 06:36:01 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id 280313A6809 for ; Thu, 26 Aug 2010 06:36:00 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id 35628716C5 for ; Thu, 26 Aug 2010 13:36:32 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 9EDE163B101; Thu, 26 Aug 2010 13:36:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 27A6B63B100 for ; Thu, 26 Aug 2010 13:36:16 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA26874; Thu, 26 Aug 2010 09:36:15 -0400 (EDT) Date: Thu, 26 Aug 2010 09:36:15 -0400 (EDT) From: der Mouse Message-Id: <201008261336.JAA26874@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 26 Aug 2010 09:25:59 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 In-Reply-To: References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <20100825154113.GT17097@oracle.com> <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>> Why is a global request needed? >> It's not really _needed_. It is designed to allow the client to >> probe for the presence of support earlier than the channel request >> does. > Why do you need to probe for that early? Don't really _need_ to. I just would like to be able to error out of the client early if the user specifies forwardings and the server doesn't support them at all. It certainly would be a fairly small loss to remove the global-request aspect of it entirely. > And *if* you decide to do the channel association thing (rather than > multiple data types on a single channel), consider how that mechanism > works together with association of x11 channels with the > corresponding session (lacking in the RFCs, but IIRC you have some > alternative x11 messages of your own that do set that up this more > properly). Right, I do. (And, actually, the RFC spec does permit it, by shoehorning the relevant info into the unnecessary X11 cookie data.) That's an interesting point; X11 connections, and for that matter forwarded TCP connections, are something approaching prior art here. I should try to take what hints I can from them. > *** Security implications of unexpected fds *** > [...] Yes. Like any facility, this is one of the things that may need to be restricted or eliminated for limited-access users. As long as the protocol doesn't make it difficult or impossible somehow (which I don't think any of the ideas so far do), this is just a quality-of-implementation issue. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Aug 26 06:43:37 2010 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A0D3A6974 for ; Thu, 26 Aug 2010 06:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nRTzgDhz7fq for ; Thu, 26 Aug 2010 06:43:36 -0700 (PDT) Received: from mollari.NetBSD.org (mollari.NetBSD.org [IPv6:2001:4f8:3:7:230:48ff:fed3:af12]) by core3.amsl.com (Postfix) with ESMTP id B358C3A6981 for ; Thu, 26 Aug 2010 06:43:35 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK)) by mollari.NetBSD.org (Postfix) with ESMTPS id EBF81716C5 for ; Thu, 26 Aug 2010 13:44:07 +0000 (UTC) Received: by mail.netbsd.org (Postfix, from userid 0) id 47DD463B101; Thu, 26 Aug 2010 13:43:54 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [130.236.254.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id A6F4063B100 for ; Thu, 26 Aug 2010 13:43:51 +0000 (UTC) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id o7QCswUO028089; Thu, 26 Aug 2010 14:54:58 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id o7QCswoe028088; Thu, 26 Aug 2010 14:54:58 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: fds beyond 0/1/2 References: <201008251412.KAA20207@Sparkle.Rodents-Montreal.ORG> <201008251532.LAA20885@Sparkle.Rodents-Montreal.ORG> <20100825154113.GT17097@oracle.com> <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> Date: Thu, 26 Aug 2010 14:54:58 +0200 In-Reply-To: <201008251754.NAA21489@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Wed, 25 Aug 2010 13:54:17 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list der Mouse writes: Some comments, without reading the proposal too carefully: *** Global probing request *** >> Why is a global request needed? > > It's not really _needed_. It is designed to allow the client to probe > for the presence of support earlier than the channel request does. Why do you need to probe for that early? If you need that only in obscure cases, why not just 1. open a session channel, 2. send the channel-request and observe the reply 3. close the session channel again Although I have difficulty seeing why you'd ever need to do that in advance of actually trying to set up the real session with the various extra fd:s. If you want to go forward, I'd suggest specifying the fd forwarding features (preferably as minimalistic as possible), and then leave out "early probing for random features" until some clear need for that is demonstrated. I think that ought to be an orthogonal issue. *** Channel association *** And *if* you decide to do the channel association thing (rather than multiple data types on a single channel), consider how that mechanism works together with association of x11 channels with the corresponding session (lacking in the RFCs, but IIRC you have some alternative x11 messages of your own that do set that up this more properly). *** Security implications of unexpected fds *** When the ssh server is intended to give only limited access to a user (only certain subsystems, or only exec requests with certain commands), I can imagine that the started process might be confused or even compromized if it is started with random fd's being open. E.g., some crucial libc functions may fail if no fd:s below 256 are available. So in this case, the client's ability to request that arbitrary fds be opened may need to be restricted. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.