From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 2 14:24:56 2009 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 B6C3F3A7107 for ; Wed, 2 Sep 2009 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 xegYovI-ZJrU for ; Wed, 2 Sep 2009 14:24:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0097C3A7118 for ; Wed, 2 Sep 2009 14:22:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7647563B10F; Wed, 2 Sep 2009 21:22:08 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by mail.netbsd.org (Postfix) with ESMTP id DABA463B100 for ; Wed, 2 Sep 2009 21:22:06 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82KCxHl018392 for ; Wed, 2 Sep 2009 20:12:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82KCxtC003046 for ; Wed, 2 Sep 2009 14:12:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n82JsXdP009337; Wed, 2 Sep 2009 14:54:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n82JsXiU009336; Wed, 2 Sep 2009 14:54:33 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 2 Sep 2009 14:54:33 -0500 From: Nicolas Williams To: ietf@ietf.org Cc: ietf-ssh@NetBSD.org Subject: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell) Message-ID: <20090902195433.GR1033@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Individual submission I-Ds that don't fall in the purview of a chartered WG do not require WGLC, only IETF Last Call, with a double-length IETF LC. Thus RFC5647 (AES-GCM for Secure Shell) was published with only IETF LC -- there was no WG in which to run a WGLC. However, there had recently (April 2009) been a lengthy thread on the old SECSH WG mailing list (Cc'ed) about this very topic. A heads-up should have been sent to that list. I do not subscribe to the IETF list (ietf@ietf.org), for the very obvious reason that its signal-to-noise ratio is too poor, thus completely missed the IETF LC of draft-igoe- secsh-aes-gcm -- but I would not have missed a heads up on the ietf-ssh@NetBSD.org list! Let's fix the IETF LC for individual submissions process. My recommendations: - Whenever there is a concluded WG [whose list remains in operation] that would have been a suitable WG for WGLC of an individual submission I-D, had that WG not been concluded, then send a heads up to that old WG's list. - Establish a separate list for IETF LC, or even one IETF LC list per-area. This will improve the signal-to-noise ratio, and will encourage wider review of individual submission I-Ds. Incidentally, only two weeks ago I was asked by a Security AD to initiate a "pseudo-WGLC" in WGs whose scope my I-D was outside. I gladly complied. The situation there was analogous to, though not exactly the same as, the situation with respect to draft-igoe-secsh-aes- gcm (now RFC5647). Why could a pseudo-WGLC in the concluded SECSH WG list not have been used? It's entirely possible that the notion of a pseudo-WGLC only just came up, that it was too late for draft-igoe-secsh-aes-gcm. But even so, a notion of "pseudo-WGLC" is too informal; we need a better solution than "hope the current ADs think of asking for a pseudo-WGLC" (no offense meant to the current ADs -- I'm worried about future cases). Comments? Please follow up the above comments on the ietf@ietf.org list, Cc' me, and drop the ietf-ssh@NetBSD.org list from the Cc list. -------------------------------------------------------------------------------- All that said, I'm reasonably happy with RFC5647, but there are several issues that I think should have been addressed prior to publication: - Nit: we don't call SSHv2 connections "tunnels". - Clarification: The initialization of the 'invocation_counter' and 'fixed' portions of the GCM nonce, and their semantics need more description. Specifically: - 'fixed' _appears_ to be the four left-most octets from the c-to-s or s-to-c "IVs" (one for each direction), while 'invocation_counter' _appears_ to be initialized to the eight right-most octets of the corresponding IV. This clarification seems obvious enough. - The 'invocation_counter' wraps around to zero, but if normalized to zero it is expected never to wrap to zero. This clarification seems obvious enough as well. - 'fixed' appears to be fixed per-_key exchange_, not for the life of the connection. This one, in particular, is a complete and utter guess on my part. These are not stated or not stated clearly. I will send e-mail to the authors and the old SECSH WG list to propose errata. - Also, a rather esoteric comment with respect to unencrypted packet lengths occurs: one could always use a variable-length encoding of packet length, padded to 32 bits with randomly generated bits. Of course, most implementations' actual TCP/IP packets would correlate with SSHv2 packet boundaries strongly enough, most of the time, that packet length would be visible regardless. And to be sure: I really don't mind the unencrypted packet lengths -- that's how SSHv2 should have been from the get-go! Being robbed of the opportunity to flog such a horrible idea at the authors is not really a problem :) I wouldn't bother with that idea, but I'd have enjoyed pointing it out! :) Please follow up to the comments on RFC5647 on the old SECSH WG list. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 2 16:04:48 2009 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 AE5D228C451 for ; Wed, 2 Sep 2009 16:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.84 X-Spam-Level: X-Spam-Status: No, score=-6.84 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, 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 td1kOR-2sEQh for ; Wed, 2 Sep 2009 16:04:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6BD8828C312 for ; Wed, 2 Sep 2009 16:04:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 874CB63B112; Wed, 2 Sep 2009 23:04:55 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id 6F89163B101 for ; Wed, 2 Sep 2009 23:04:54 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82KPvpa003857 for ; Wed, 2 Sep 2009 20:25:57 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n82KPvls044920 for ; Wed, 2 Sep 2009 14:25:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n82KF3AK009352 for ; Wed, 2 Sep 2009 15:15:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n82KF3xG009351 for ietf-ssh@NetBSD.org; Wed, 2 Sep 2009 15:15:03 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 2 Sep 2009 15:15:03 -0500 From: Nicolas Williams To: ietf-ssh@NetBSD.org Subject: Re: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell) Message-ID: <20090902201503.GO1048@Sun.COM> References: <20090902195433.GR1033@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902195433.GR1033@Sun.COM> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Sep 02, 2009 at 02:54:33PM -0500, Nicolas Williams wrote: > All that said, I'm reasonably happy with RFC5647, but there are several > issues that I think should have been addressed prior to publication: > > - 'fixed' appears to be fixed per-_key exchange_, not for the life > of the connection. This one, in particular, is a complete and > utter guess on my part. I should point out that it's obvious enough that 'fixed' is fixed per-_key exchange_ simply because otherwise security would be compromised after more than 2^64 invocations. Other comments: - The algorithm names registered by this RFC with the IANA do NOT match the style of naming of previously existing algorithm names. The previous alg names were all lower-case LDH (letters digits and hyphens). The new ones are all upper-case letters, digits, and underscore. Earlier versions of the I-D had alg names with the "proper" style. What happened? - The Security Considerations section is silent on re-keying requirements (i.e., when and how often to re-key). It should not have been. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 3 01:53:04 2009 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 909493A6A8D for ; Thu, 3 Sep 2009 01:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599] 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 0xlURNroDO4O for ; Thu, 3 Sep 2009 01:53:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4892C3A68D3 for ; Thu, 3 Sep 2009 01:53:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6ACEF63B124; Thu, 3 Sep 2009 08:52:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by mail.netbsd.org (Postfix) with ESMTP id 2D43263B176 for ; Thu, 3 Sep 2009 08:52:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D67BBD6270; Thu, 3 Sep 2009 11:52:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+Fk87GncLOd; Thu, 3 Sep 2009 11:52:48 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3BAC9D626D; Thu, 3 Sep 2009 11:52:48 +0300 (EEST) Message-ID: <4A9F83DF.7030908@piuha.net> Date: Thu, 03 Sep 2009 11:52:47 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Nicolas Williams CC: ietf@ietf.org, ietf-ssh@NetBSD.org Subject: Re: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell) References: <20090902195433.GR1033@Sun.COM> In-Reply-To: <20090902195433.GR1033@Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas, As Brian notes, the formal messages go out on ietf-announce. However, I think all the ADs sponsoring individual documents attempt to reach the right audience. This includes personally reminding key contributors, forwarding the last call announcement to a mailing list if one is still known, etc. We also say so in our published procedures: http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html > The exact nature of the review within the IETF is not specified, but > it is expected that documents be posted for review in the relevant WG > mailing lists. Often no relevant mailing list exists, in which case > area-specific or IETF main discussion list can be used. > ... work closely related to a WG but strictly outside its charter > should always be brought to the WG's attention during review. Of course, its also easy to forget to do this in the midst of all other things that are going on. Jari From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 3 09:31:11 2009 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 1C7BD28C2F0 for ; Thu, 3 Sep 2009 09:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 XHNeytLuiDpn for ; Thu, 3 Sep 2009 09:31:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1C8FC28C263 for ; Thu, 3 Sep 2009 09:31:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8063963B131; Thu, 3 Sep 2009 16:31:11 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.netbsd.org (Postfix) with ESMTP id EF4F463B10D for ; Thu, 3 Sep 2009 16:31:09 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n83GV9xQ004854 for ; Thu, 3 Sep 2009 16:31:09 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n83GV9eN018202 for ; Thu, 3 Sep 2009 10:31:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n83GCi2u009892; Thu, 3 Sep 2009 11:12:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n83GCi0q009891; Thu, 3 Sep 2009 11:12:44 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Sep 2009 11:12:44 -0500 From: Nicolas Williams To: Jari Arkko Cc: ietf@ietf.org, ietf-ssh@NetBSD.org Subject: Re: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell) Message-ID: <20090903161243.GN1033@Sun.COM> References: <20090902195433.GR1033@Sun.COM> <4A9F83DF.7030908@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9F83DF.7030908@piuha.net> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Sep 03, 2009 at 11:52:47AM +0300, Jari Arkko wrote: > As Brian notes, the formal messages go out on ietf-announce. However, I Indeed. I completely forgot about that. I get so many IETF announcements that I didn't realize that I was not on that particular list. That's my fault, and I'm embarrassed :/ > think all the ADs sponsoring individual documents attempt to reach the > right audience. This includes personally reminding key contributors, > forwarding the last call announcement to a mailing list if one is still > known, etc. We also say so in our published procedures: > > http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html Indeed. I would not likely have missed an e-mail to the old SECSH WG. > Of course, its also easy to forget to do this in the midst of all other > things that are going on. Understood. I've subscribed to ietf-announce, so I won't miss any such individual I-D IETF LCs again. Thanks for your replies! Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Sep 11 11:58:10 2009 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 E10B63A699C for ; Fri, 11 Sep 2009 11:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Hptpacfw+9QC for ; Fri, 11 Sep 2009 11:58:10 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1281B3A6881 for ; Fri, 11 Sep 2009 11:58:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F093C63B1A1; Fri, 11 Sep 2009 18:58:35 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from web51402.mail.re2.yahoo.com (web51402.mail.re2.yahoo.com [206.190.38.181]) by mail.netbsd.org (Postfix) with SMTP id 8575663B13D for ; Fri, 11 Sep 2009 18:58:34 +0000 (UTC) Received: (qmail 44523 invoked by uid 60001); 11 Sep 2009 17:11:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252689114; bh=Um4rNSj4U8B40fWdAG2Ed5W+917tfkOJs5uLfnPG5t4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=rRiBarWw3Fd+7iA++tNTbqeQuJwEcTHdCjWezNSpFVl6MCHm4R8CIKyoweuIEpakbAHwTKHeH4lAu9sTrU4sz3YloVkCIcuMfOVwlxujjqop1IkOubQcgQJvbahnC+wn/rHbLSA1XdOjjqkzZ2V6QazEiqOq59lpazXuB6FREiQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=RF8f7gAStNM7Yl2VOtDlzqC+xxkuJcNpUPGQtuzU2GotQ+oTQ4cU53zKbq3n5m8QrNIOmr1tHUVnx20WPaSd6DBW6tgIzfIBRRTxwZdNMFScINkcV8Q0HQXPme2K8+jidgISmvM0KSXHxMaXav/HRZkbf9TTNJvbOCnAwv6cH1A=; Message-ID: <804542.42929.qm@web51402.mail.re2.yahoo.com> X-YMail-OSG: 34sFAdsVM1mOSDUGEOLRYyi7BGjPYt8AVlmuHnHrf9ww0c3ltVrp35CXIzsKFftCIhDZCyfCZywh44yk8O9sW3gCO5G0LpedFt6VVzySTlmVL8a7FUNiKccArtZasfWkmmEPjqfimGhqCsZzpa7_m_yDIFGfcY6TKARxsyw9G0v46C50JJpHeZIEMdnN1TEMPLpq_wFZ86_0dUNDEnbMdrrbQNxm.jc5LaxC0OtzCrit5LLI9o6NGnCpzQPn5SxYe2vGsB859DIyp9tuGDEL00stJqCUrKc3BsT2wgGheLHxJJgkvxQhkgc- Received: from [129.116.66.226] by web51402.mail.re2.yahoo.com via HTTP; Fri, 11 Sep 2009 10:11:54 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Fri, 11 Sep 2009 10:11:54 -0700 (PDT) From: Thomas Anderson Subject: maximum size of packets from client to server To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Per RFC4254, the maximum size field of an SSH_MSG_CHANNEL_OPEN packet places an upper bound on just how big a packet from the server to the client can be: The maximum size of a packet is in practice determined by the client (the maximum size of read or write requests that it sends, plus a few bytes of packet overhead). All servers SHOULD support packets of at least 34000 bytes (where the packet size refers to the full length, including the header above). This should allow for reads and writes of at most 32768 bytes. My question is... what about the other way around? What about packets sent from the client to the server? If I upload a 1mb file via PuTTY's PSFTP, the SSH_MSG_CHANNEL_DATA packets have a data length of 512 bytes. Why not 34000 bytes? Why not 1mb? The fact that PuTTY has a server->client max size of 16,384 bytes makes the client->server max size of 512 seem odd... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Sep 12 15:20:41 2009 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 1FD183A63EB for ; Sat, 12 Sep 2009 15:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 SXSNLEhZQQjt for ; Sat, 12 Sep 2009 15:20:40 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 248DA3A68FE for ; Sat, 12 Sep 2009 15:20:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B4F5763B1EA; Sat, 12 Sep 2009 22:21: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 3756B63B1E8 for ; Sat, 12 Sep 2009 22:21:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA15314; Sat, 12 Sep 2009 18:21:13 -0400 (EDT) From: der Mouse Message-Id: <200909122221.SAA15314@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. Date: Sat, 12 Sep 2009 18:18:44 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <804542.42929.qm@web51402.mail.re2.yahoo.com> References: <804542.42929.qm@web51402.mail.re2.yahoo.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Per RFC4254, the maximum size field of an SSH_MSG_CHANNEL_OPEN packet > places an upper bound on just how big a packet from the server to the > client can be: [...] > My question is... what about the other way around? What about > packets sent from the client to the server? See the SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet sent in response to the open request, which holds the corresponding values for data flowing in the other direction. /~\ 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 Sat Sep 12 22:40:45 2009 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 B1A473A67FC for ; Sat, 12 Sep 2009 22:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 NwJRchueFx+w for ; Sat, 12 Sep 2009 22:40:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7AC2B3A67ED for ; Sat, 12 Sep 2009 22:40:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5978563B1C4; Sun, 13 Sep 2009 05:41:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from web51412.mail.re2.yahoo.com (web51412.mail.re2.yahoo.com [206.190.39.153]) by mail.netbsd.org (Postfix) with SMTP id 1697563B12F for ; Sun, 13 Sep 2009 05:41:15 +0000 (UTC) Received: (qmail 52104 invoked by uid 60001); 13 Sep 2009 03:54:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252814074; bh=T4qytMeVC34xjbNfrwtt8xb3eKONwsXRMUPyf2mjysY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=u5oCWZfCKAdT7HTJdCxb0lXI5qD3s53qPjhJ047EbvHSjkdMYjY9EOneOUXA6z0gL/sUJdfeanANDDaufkdOmeQtJO+Kepp7svhDbwvarVtpE+XqGKDGQ8gR0rmWFlDYoEYc/33HVwlLL+Ivb+q2/1Kq14tKOSca0Bh9WI+85bk= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=T/phQSBm8FOBNddd/OKKyHJ2msmBqJA8tOe1jFNAszsh1+lrq9thR0+IIFNIOFz0iiX+BhihzVDoJ9rB/ToOaNFCgd78YWZbFijwz9s3wIfuNvAK5INSfwBumtnEnr+7SLlZtj6FMg7gDCzlPFgYhxb5OdetzBGoEfA3IdCR6Iw=; Message-ID: <264346.52087.qm@web51412.mail.re2.yahoo.com> X-YMail-OSG: CX.SP2AVM1m_s5bC04..SNneScKGjM30yy1CAV9O7yvbZIrGung7NBk98WYN.u17vCrgIrJI8sJZzuPyytETuqu7htB0YlxRB1YU0BzcHxNv92HLskR2_kaLGYzsmYKVfvkt640I_.syLGoq.Z1ExSzrMaZ9sYzPuTghNauE27z0_PzuNXxKI34TSshX6nsvSR5Vr.wrLXUDeBQwgk44szcPyxyj0ofaTKovSb4.adnJ1oGExvHo4JhFs8QBOzQ2dJ3lw1WLfAoBl.B5wYMyQpJzoAM2Num8VV5r3dDG68i7Mbo6B9TE Received: from [70.116.12.67] by web51412.mail.re2.yahoo.com via HTTP; Sat, 12 Sep 2009 20:54:34 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Sat, 12 Sep 2009 20:54:34 -0700 (PDT) From: Thomas Anderson Subject: Re: maximum size of packets from client to server To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse wrote: >> Per RFC4254, the maximum size field of an SSH_MSG_CHANNEL_OPEN packet >> places an upper bound on just how big a packet from the server to the >> client can be: [...] > >> My question is... what about the other way around? What about >> packets sent from the client to the server? > > See the SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet sent in response to > the open request, which holds the corresponding values for data flowing > in the other direction. Hmmm - the first time I looked at the structure of SSH_MSG_CHANNEL_OPEN_CONFIRMATION, I thought those extra fields were for confirmation purposes and didn't give it a second thought. Seems like the RFC should maybe state their purpose in SSH_MSG_CHANNEL_OPEN_CONFIRMATION a bit more explicitly - as is, although it's clear what they mean for SSH_MSG_CHANNEL_OPEN, for the confirmation response, it kinda requires you guess. Maybe it's an easy enough thing to guess correctly, but I, apparently, didn't... Anyway, thanks! From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Sep 13 03:53:26 2009 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 246423A6828 for ; Sun, 13 Sep 2009 03:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.18 X-Spam-Level: X-Spam-Status: No, score=-8.18 tagged_above=-999 required=5 tests=[AWL=1.808, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 2wP2VG+yOZ-Y for ; Sun, 13 Sep 2009 03:53:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4BEF43A6830 for ; Sun, 13 Sep 2009 03:53:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D21863B146; Sun, 13 Sep 2009 10:54:04 +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 8E50F63B120 for ; Sun, 13 Sep 2009 10:54:02 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id GAA19219; Sun, 13 Sep 2009 06:54:01 -0400 (EDT) From: der Mouse Message-Id: <200909131054.GAA19219@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. Date: Sun, 13 Sep 2009 06:43:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <264346.52087.qm@web51412.mail.re2.yahoo.com> References: <264346.52087.qm@web51412.mail.re2.yahoo.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> My question is... what about the other way around? What about >>> packets sent from the client to the server? >> See the SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet [...] > Hmmm - the first time I looked at the structure of > SSH_MSG_CHANNEL_OPEN_CONFIRMATION, I thought those extra fields were > for confirmation purposes and didn't give it a second thought. Seems > like the RFC should maybe state their purpose in > SSH_MSG_CHANNEL_OPEN_CONFIRMATION a bit more explicitly - Agreed. When (if) 4254 is updated, that's a change I'd like to see; as it stands, it is entirely silent on the purpose of those fields, which strikes me as a bad idea for a formal spec. /~\ 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 Sun Sep 13 20:06:15 2009 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 CC99F3A680D for ; Sun, 13 Sep 2009 20:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 ftfMdSBeLFTU for ; Sun, 13 Sep 2009 20:06:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E15783A66B4 for ; Sun, 13 Sep 2009 20:06:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C052E63B231; Mon, 14 Sep 2009 03:06:49 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from web51408.mail.re2.yahoo.com (web51408.mail.re2.yahoo.com [206.190.38.187]) by mail.netbsd.org (Postfix) with SMTP id 40D7063B111 for ; Mon, 14 Sep 2009 03:06:47 +0000 (UTC) Received: (qmail 90897 invoked by uid 60001); 14 Sep 2009 01:20:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252891206; bh=tsq3us/DDkCFLVt/JIvZGdLKwbFz5kh+r8vPnUpafuw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=qFkkhmTiJjAK4NR3/5TYNNHHzSvG5AxmvU7cNVxRPen9fjEWdVeZiazzR9qeII5N/0SnzcsX0pWGENauASEJ8NWamy8Vma6gX97RpU30/3f2sGTHK+iXe9Kzv8P2nM7U7QW9jIXlEyLCfKK5tA26pUwCb9j7IAx7AB12rLolo1s= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=f4Yi66LbEtVUEF2T4XzPNnuLZq2m36i544tbQ/AKVCaaVbXuANxblEZYeQ540tJIQ/PmkkoQMK120ESAYjXR6pzlsngtklrKPT3B0oggGYXlm+gP0KqWb5WG9kKr2OOWuipnQW5/A5hIEOIEdoXFEr5e+If+saeUZiZE2SM968Y=; Message-ID: <630097.90189.qm@web51408.mail.re2.yahoo.com> X-YMail-OSG: qEUd8IYVM1koabwCgJScHq6_AGolWjl94omp3iPRxCfl3SHluVvCjbX.WY37eJ8t10SAcYp4ALmch9VB8Vu2hKGlQ3Q1w2d5lSfSBr8TkocmRnGh5Le2lms0h9UXgN2_uvi1cs5N2nnfzVvnheWMpoYY5TwBv8XoCFZHpfSO5MIW2agdRYyVH..PBhNTSIabltXGEm9yQCT_TAleHDVlZWAVZLkioc_GlwxrNf7kd2f9iWIM6G7hY.Iss1hkchrnga12gBzadRN0WLAbdUpJfLozwMNmsyYygsfg6PPR97QN1GDqJD6soDHm0t0vKs0Or7T_eTpjATGcrT7x Received: from [70.116.12.67] by web51408.mail.re2.yahoo.com via HTTP; Sun, 13 Sep 2009 18:20:06 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Sun, 13 Sep 2009 18:20:06 -0700 (PDT) From: Thomas Anderson Subject: Re: maximum size of packets from client to server To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse wrote: > > > Agreed. When (if) 4254 is updated, that's a change I'd like to see; as > it stands, it is entirely silent on the purpose of those fields, which > strikes me as a bad idea for a formal spec. On this same subject, here's something else I think could use clarification. RFC4254#section-5.1 states that the "maximum packet size" refers to the "maximum size of an individual data packet". This raises the question... what qualifies as a data packet. Does SSH_MSG_CHANNEL_REQUEST qualify as a data packet, for example? Often, they wouldn't, but if the request type is "exec", a SSH_MSG_CHANNEL_REQUEST could easily exceed "maximum packet size". The fact that RFC4254#section-5.2 (Data Transfer) repeats the bit about the "maximum packet size" while RFC4254#section-6.5 (Starting a Shell or a Command) doesn't suggests to me that SSH_MSG_CHANNEL_REQUEST is not a data packet, but it seems like it should be discussed in #section-5.1's discussion of the "maximum packet size", none-the-less. Also, it's not clear to me what the maximum packet size is referring to. If it's 16,384 bytes, does that mean that the largest binary packet that you can have, if you hav a block size of 24 bytes (eg. aes192-cbc), is 16,368 bytes, or does it mean that the largest data string you can have is 16,384 bytes? I would assume that it's the largest data string since the binary packets can be compressed and since it'd be hard to know if the string to be compressed was small enough until after you compressed it. Also, if the maximum maximum packet size of 32,768 bytes referred to the maximum size of the binary packet, then it seems like the whole "total packet length of 35,000 bytes" of RFC4253#section-6.1 would be somewhat unnecessary as the practical limit would be 32,768 bytes - not 35,000. Either way, it seems like this should be elaborated upon in RFC4254 as well. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Sep 13 22:56:35 2009 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 664FA3A68DC for ; Sun, 13 Sep 2009 22:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.783 X-Spam-Level: X-Spam-Status: No, score=-8.783 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 nlU2V16nxFxT for ; Sun, 13 Sep 2009 22:56:34 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 754963A68DB for ; Sun, 13 Sep 2009 22:56:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7AEA763B111; Mon, 14 Sep 2009 05:57:09 +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 BCD8B63B103 for ; Mon, 14 Sep 2009 05:57:07 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id BAA29258; Mon, 14 Sep 2009 01:57:03 -0400 (EDT) From: der Mouse Message-Id: <200909140557.BAA29258@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. Date: Mon, 14 Sep 2009 01:42:40 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > The SSH spec doesn't really explain the semantics of the server's > response to the channel open command, in particular whether the > returned data size parameters are merely a confirmation of the > client's requested values or whether the server is allowed to > further modify them to suit its own requirements (or perhaps one is > for send and the other for receive?). I thought it was obvious, but here we have three people thinking of three different interpretations, so it clearly isn't as obvious as I thought. (The main reason I considered it obvious is that neither of the other two interpretations seems useful to me: echoing back the values is pointless, since the channel open initiator (which may or may not be the client) already has them, and the channel open confirmer may use a smaller max packet size when sending data if it feels like it but there's no need to tell the open initiator about it. The only case where sending those values is actually useful is when they describe the maximum packet size for packets from the confirmer to the initiator (whether the same value applies to the first direction also or not is open for discussion, but see below). And there needs to be a way for the open confirmer to tell the open initiator what max packet size to use; the open confirmer may impose a lower limit than the open initiator does.) > So my code treats the incoming size as being the same as the outgoing > size, and so far has never run into problems. I'd prefer to see this > behaviour retained, since there doesn't seem to be anything making > use of the capability for asymmetric sizes (or at least nothing I've > run into), so explicitly introducing this is just going to add a pile > of new exception and error states that need to be handled. I'd prefer to see the two sizes explicitly separated, since everything else about the two directions is independent and I see no reason to introduce an exception for this. I don't see it as introducing any new exception or error states; all the exception states I can see already exist. The only difference is whether the value being compared against always equals the value used as the maximum when constructing outgoing packets. One thing I would like to see clarified here but haven't seen mentioned is what level the max packet size applies at. Is it the max data payload of a CHANNEL_DATA (or CHANNEL_EXTENDED_DATA) packet, the max size of a CHANNEL_DATA (or ...) packet in cleartext form, the max size of such a packet with encryption and padding, what? /~\ 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 Sun Sep 13 23:25:34 2009 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 803633A69AA for ; Sun, 13 Sep 2009 23:25:34 -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 4XeOLGT17tOQ for ; Sun, 13 Sep 2009 23:25:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 875033A699E for ; Sun, 13 Sep 2009 23:25:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F372B63B11B; Mon, 14 Sep 2009 06:26:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mail.netbsd.org (Postfix) with ESMTP id 3CFF863B14D for ; Mon, 14 Sep 2009 06:26:07 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7AC35669BAB; Mon, 14 Sep 2009 17:19:54 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbUrFNZyrSlr; Mon, 14 Sep 2009 17:19:54 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8806A669B6C; Mon, 14 Sep 2009 17:19:51 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6621619EC0BC; Mon, 14 Sep 2009 17:19:48 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Mn3ye-0005jg-7b; Mon, 14 Sep 2009 17:19:48 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: maximum size of packets from client to server In-Reply-To: <200909131054.GAA19219@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Mon, 14 Sep 2009 17:19:48 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: >When (if) 4254 is updated, that's a change I'd like to see; as it stands, it >is entirely silent on the purpose of those fields, which strikes me as a bad >idea for a formal spec. Ditto. My code's handling of this is: The SSH spec doesn't really explain the semantics of the server's response to the channel open command, in particular whether the returned data size parameters are merely a confirmation of the client's requested values or whether the server is allowed to further modify them to suit its own requirements (or perhaps one is for send and the other for receive?). In the absence of any further guidance we just ignore the returned values, which seems to work for all deployed servers. So my code treats the incoming size as being the same as the outgoing size, and so far has never run into problems. I'd prefer to see this behaviour retained, since there doesn't seem to be anything making use of the capability for asymmetric sizes (or at least nothing I've run into), so explicitly introducing this is just going to add a pile of new exception and error states that need to be handled. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 14 00:51:27 2009 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 7840828C124 for ; Mon, 14 Sep 2009 00:51:27 -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_36=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 mb1FVkaaJ9N2 for ; Mon, 14 Sep 2009 00:51:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7DB4428C120 for ; Mon, 14 Sep 2009 00:51:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AA72C63B15B; Mon, 14 Sep 2009 07:52:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id 7223263B103 for ; Mon, 14 Sep 2009 07:52:05 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DDB8B4141F4; Mon, 14 Sep 2009 18:04:49 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mywFo1O63xB; Mon, 14 Sep 2009 18:04:49 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BFF2741419F; Mon, 14 Sep 2009 18:04:49 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 65A0519EC0BC; Mon, 14 Sep 2009 18:04:49 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Mn4gD-0007tY-9a; Mon, 14 Sep 2009 18:04:49 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: maximum size of packets from client to server In-Reply-To: <200909140557.BAA29258@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Mon, 14 Sep 2009 18:04:49 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: >The main reason I considered it obvious is that neither of the other two >interpretations seems useful to me: echoing back the values is pointless, >since the channel open initiator (which may or may not be the client) already >has them, and the channel open confirmer may use a smaller max packet size >when sending data if it feels like it but there's no need to tell the open >initiator about it. The reason why the second interpretation could be argued to be useful is if you see the exchange as: Client: I propose a max.packet size of 128 MB. Server: That looks a bit large to me, how about 64kB? So the client is advertising what it's prepared to accept as a maximum, and the server is either confirming it or saying it'd prefer a bit less, an exchange a bit like some of the cipher suite-type negotiation. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 14 01:02:09 2009 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 5165B3A681F for ; Mon, 14 Sep 2009 01:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 A3YfwnOPLtdv for ; Mon, 14 Sep 2009 01:02:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 467F23A67B8 for ; Mon, 14 Sep 2009 01:02:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E625263B1CB; Mon, 14 Sep 2009 08:02:41 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 82BEC63B103 for ; Mon, 14 Sep 2009 08:02:39 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 609B040019; Mon, 14 Sep 2009 10:01:56 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 5477340015; Mon, 14 Sep 2009 10:01:56 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 39EC540015; Mon, 14 Sep 2009 10:01:56 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8E82aSw018211; Mon, 14 Sep 2009 10:02:36 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8E82ZO1018210; Mon, 14 Sep 2009 10:02:35 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server References: <200909140557.BAA29258@Sparkle.Rodents-Montreal.ORG> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 14 Sep 2009 10:02:35 +0200 In-Reply-To: <200909140557.BAA29258@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Mon, 14 Sep 2009 01:42:40 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: > I thought it was obvious, Me too. I found it fairly clear that the two directions of a channel are mostly independent and that each direction has it's own values for window size and maximum packet size. > One thing I would like to see clarified here but haven't seen mentioned > is what level the max packet size applies at. Again, I couldn't agree more. I interpret it as a maximum data payload in CHANNEL_DATA / CHANNEL_EXTENDED_DATA. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 14 02:15:52 2009 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 1C0543A69F4 for ; Mon, 14 Sep 2009 02:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 vH8fupSy5F1B for ; Mon, 14 Sep 2009 02:15:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3D8A53A69EE for ; Mon, 14 Sep 2009 02:15:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DFEBA63B1D8; Mon, 14 Sep 2009 09:16:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 2BEAF63B103 for ; Mon, 14 Sep 2009 09:16:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BB72540015; Mon, 14 Sep 2009 10:09:47 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id AF17C40019; Mon, 14 Sep 2009 10:09:47 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 91A2240015; Mon, 14 Sep 2009 10:09:47 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8E8ASdh018371; Mon, 14 Sep 2009 10:10:28 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8E8AS32018370; Mon, 14 Sep 2009 10:10:28 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Thomas Anderson Cc: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server References: <630097.90189.qm@web51408.mail.re2.yahoo.com> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 14 Sep 2009 10:10:27 +0200 In-Reply-To: <630097.90189.qm@web51408.mail.re2.yahoo.com> (Thomas Anderson's message of "Sun, 13 Sep 2009 18:20:06 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Thomas Anderson writes: > On this same subject, here's something else I think could use > clarification. RFC4254#section-5.1 states that the "maximum packet > size" refers to the "maximum size of an individual data packet". > This raises the question... what qualifies as a data packet. Does > SSH_MSG_CHANNEL_REQUEST qualify as a data packet, for example? I'd say it doesn't qualify. Both window size and channel max packet size apply to the data flow (CHANNEL_DATA, CHANNEL_EXTENDED_DATA) of a channel, in one direction. > Also, it's not clear to me what the maximum packet size is referring > to. I agree this is unclear. It makes the most sense to me to apply it to the data payload only. The following comment explains how I apply the various limits when reading data from some source, to be transmitted over an ssh channel as CHANNEL_DATA or CHANNEL_EXTENDED_DATA: /* There are three numbers that limit the amount of data we can read: * * 1 The current send_window_size. * 2 The send_max_packet size for the channel. * 3 (The maximum size for a complete packet SSH_MAX_PACKET) * * We don't enforce (3) here, but assume that if the remote end has * given us a huge send_max_packet, it will also handle huge ssh * packets. */ Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 14 02:49:13 2009 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 EE03F3A69FB for ; Mon, 14 Sep 2009 02:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3] 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 RJC4jhqmXhrr for ; Mon, 14 Sep 2009 02:49:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 263D83A684C for ; Mon, 14 Sep 2009 02:49:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 28C2663B134; Mon, 14 Sep 2009 09:49:49 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 D856763B103 for ; Mon, 14 Sep 2009 09:49:47 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0CE5140019; Mon, 14 Sep 2009 10:22:50 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id F3BD24001E; Mon, 14 Sep 2009 10:22:49 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id E308D40019; Mon, 14 Sep 2009 10:22:49 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8E8NUxw018751; Mon, 14 Sep 2009 10:23:30 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8E8NT5x018750; Mon, 14 Sep 2009 10:23:29 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Peter Gutmann Cc: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: maximum size of packets from client to server References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 14 Sep 2009 10:23:28 +0200 In-Reply-To: (Peter Gutmann's message of "Mon, 14 Sep 2009 18:04:49 +1200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Peter Gutmann writes: > The reason why the second interpretation could be argued to be useful is if > you see the exchange as: > > Client: I propose a max.packet size of 128 MB. > Server: That looks a bit large to me, how about 64kB? But the server can lower the value however it likes, without telling the client. Like Client: I can accept packets of size up to 128 MB. Server: That's too high for my taste. I'll just pretend that the client said only 64kB. You might argue that it would be useful for the client to know that this server has decided to not send any packets larger than 64kB, but I'd say that really getting any advantage out of that information is too much complexity for too small gain. (And same goes with the roles of client and server reversed, of course). Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 14 05:22:11 2009 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 F03C43A6851 for ; Mon, 14 Sep 2009 05:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.784 X-Spam-Level: X-Spam-Status: No, score=-8.784 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8] 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 HYEow7n4hiLk for ; Mon, 14 Sep 2009 05:22:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 234753A680E for ; Mon, 14 Sep 2009 05:22:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5FFAD63B15F; Mon, 14 Sep 2009 12:22:48 +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 0658563B103 for ; Mon, 14 Sep 2009 12:22:45 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA01044; Mon, 14 Sep 2009 08:22:44 -0400 (EDT) From: der Mouse Message-Id: <200909141222.IAA01044@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. Date: Mon, 14 Sep 2009 08:05:30 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> and the channel open confirmer may use a smaller max packet size >> when sending data if it feels like it but there's no need to tell >> the open initiator about it. > The reason why the second interpretation could be argued to be useful > is if you see the exchange as: > Client: I propose a max.packet size of 128 MB. > Server: That looks a bit large to me, how about 64kB? Yes, but, as Niels pointed out, there's no need for the server to tell the client it's lowering the effective value. ...unless, of course, you see this as being a single value negotiated for both directions at once, rather than a limit on just the size of server->client packets. This is a self-consistent point of view, of course; the major thing I see going against it is that it violates the way everything else is determined separately for the two directions. I suspect the reason you haven't run into any interop issues with your interpretation is that everything (or at least everything you've interop tested against) uses (approximately) the same limit you do. Try artificially lowering your max-packet value to, say, 64 octets, and see what happens. (And, of course, nothing says that the one sending the CHANNEL_OPEN is the client and the one sending the CHANNEL_OPEN_CONFIRMATION is the server; either end may initiate channel opens.) /~\ 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 Mon Sep 14 19:48:31 2009 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 BF7A53A682A for ; Mon, 14 Sep 2009 19:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619, STOX_REPLY_TYPE=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 e2pa7a9JCy16 for ; Mon, 14 Sep 2009 19:48:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D4EE73A6954 for ; Mon, 14 Sep 2009 19:48:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D7B2863B298; Tue, 15 Sep 2009 02:49:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (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 A7E2063B28E for ; Tue, 15 Sep 2009 02:49:06 +0000 (UTC) Received: from element ([209.59.72.219]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Mon, 14 Sep 2009 21:49:09 -0400 Message-ID: <8D5F6CBE0FAE41D790DC84751E4BCD53@element> From: "denis bider \(Bitvise\)" To: References: <200909140557.BAA29258@Sparkle.Rodents-Montreal.ORG> In-Reply-To: Subject: Re: maximum size of packets from client to server Date: Mon, 14 Sep 2009 21:47:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> I thought it was obvious, > > Me too. I found it fairly clear that the two directions of a channel > are mostly independent and that each direction has it's own values for > window size and maximum packet size. I must agree. This interpretation is obvious, sensible, and is in the spirit of the SSH protocol. This is why the spec doesn't spell it out (though I agree it should). I think Peter's interpretation is unreasonable. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 15 00:08:18 2009 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 E1E8D3A6966 for ; Tue, 15 Sep 2009 00:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 RIYDf5-ry2nm for ; Tue, 15 Sep 2009 00:08:18 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E9BE33A6782 for ; Tue, 15 Sep 2009 00:08:17 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 20BE763B128; Tue, 15 Sep 2009 07:08:55 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mail.netbsd.org (Postfix) with ESMTP id F00AC63B10F for ; Tue, 15 Sep 2009 07:08:52 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8FC1D17119E; Tue, 15 Sep 2009 17:09:35 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ij57rzbe9m5; Tue, 15 Sep 2009 17:09:35 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7029017063B; Tue, 15 Sep 2009 17:09:33 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A367719EC0BC; Tue, 15 Sep 2009 17:09:32 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1MnQIG-0003uq-GS; Tue, 15 Sep 2009 17:09:32 +1200 From: Peter Gutmann To: ietf-ssh2@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <8D5F6CBE0FAE41D790DC84751E4BCD53@element> Message-Id: Date: Tue, 15 Sep 2009 17:09:32 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list "denis bider (Bitvise)" writes: >I must agree. This interpretation is obvious, sensible, and is in the spirit >of the SSH protocol. This is why the spec doesn't spell it out (though I >agree it should). If it's so obvious then why have a number of different people been unable to guess the "obvious" interpretation? If implementors are having difficulty interpreting what the spec is trying to say then by definition it cannot be "obvious". Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 15 17:22:15 2009 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 0FAC83A692E for ; Tue, 15 Sep 2009 17:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 OnWufz+JA9Ve for ; Tue, 15 Sep 2009 17:22:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2BE9E3A67A3 for ; Tue, 15 Sep 2009 17:22:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8C8BF63B33D; Wed, 16 Sep 2009 00:22:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [216.184.10.33]) by mail.netbsd.org (Postfix) with ESMTP id 492EB63B135 for ; Wed, 16 Sep 2009 00:22:56 +0000 (UTC) Received: from [192.168.1.193] (account galb [192.168.1.193] verified) by vandyke.com (CommuniGate Pro SMTP 5.0.9) with ESMTPA id 5455047; Tue, 15 Sep 2009 17:22:54 -0600 Message-ID: <4AB02174.3060105@vandyke.com> Date: Tue, 15 Sep 2009 17:21:24 -0600 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: der Mouse , ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server References: <200909140557.BAA29258@Sparkle.Rodents-Montreal.ORG> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Niels Möller wrote: > der Mouse writes: > >> I thought it was obvious, > > Me too. I found it fairly clear that the two directions of a channel > are mostly independent and that each direction has it's own values for > window size and maximum packet size. > >> One thing I would like to see clarified here but haven't seen mentioned >> is what level the max packet size applies at. > > Again, I couldn't agree more. I interpret it as a maximum data payload > in CHANNEL_DATA / CHANNEL_EXTENDED_DATA. I agree this is unclear. We don't enforce anything for max packet size (other than the 35K limit at the transport level), and for the purposes of sending, I interpreted the max packet as the maximum size of the outgoing SSH packet before compression and encryption. Maximum size of the data payload would be a heck of a lot easier though ... I'd prefer a different name if it doesn't actually refer to the packet. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 15 17:33:16 2009 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 0DE603A6AB0 for ; Tue, 15 Sep 2009 17:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619, STOX_REPLY_TYPE=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 LtFUYA92aZmc for ; Tue, 15 Sep 2009 17:33:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 39BB63A6A61 for ; Tue, 15 Sep 2009 17:33:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9364563B33A; Wed, 16 Sep 2009 00:33:57 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (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 7F38063B135 for ; Wed, 16 Sep 2009 00:33:56 +0000 (UTC) Received: from element ([209.59.72.219]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Tue, 15 Sep 2009 20:33:48 -0400 Message-ID: <4CB1BC9530374019A3A175E67010384A@element> From: "denis bider \(Bitvise\)" To: References: In-Reply-To: Subject: Re: maximum size of packets from client to server Date: Tue, 15 Sep 2009 20:33:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>I must agree. This interpretation is obvious, sensible, and is in the >>spirit >>of the SSH protocol. This is why the spec doesn't spell it out (though >>I >>agree it should). > > If it's so obvious then why have a number of different people been > unable > to guess the "obvious" interpretation? The "number of different people" that you refer to is 1. Thomas is a newbie who understood the concept the instant it was explained. > If implementors are having difficulty interpreting what the spec is > trying > to say then by definition it cannot be "obvious". It's not obvious to you because you've always refused to accept SSH the way it is, and have always tried to shoehorn it into something it is not - something more along your way of doing things, not necessarily bad, but idiosyncratic. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 15 21:42:52 2009 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 DAE313A683A for ; Tue, 15 Sep 2009 21:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_05=-1.11] 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 hQ0QHqTecqIB for ; Tue, 15 Sep 2009 21:42:50 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 34ED13A6846 for ; Tue, 15 Sep 2009 21:42:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4534F63B143; Wed, 16 Sep 2009 04:43:32 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from web51407.mail.re2.yahoo.com (web51407.mail.re2.yahoo.com [206.190.38.186]) by mail.netbsd.org (Postfix) with SMTP id AC45263B154 for ; Wed, 16 Sep 2009 04:43:30 +0000 (UTC) Received: (qmail 52584 invoked by uid 60001); 16 Sep 2009 02:56:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253069808; bh=OzmSFF73K66Z0x3TIVXrsXinbnpyBPl9Tll81MTACe8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=b2uaq3AYFAKaPh99DuKEPlmbUGDcR+yxfpUusWEXXgjv2OXsI/z4B3jgNRPrxJAiEsd80Sy3M7jl3IhGloJuQ9ytGxl0D3q8OqGNMc4WZej1tOABHceMDLmEb3HRsXaIbLoNgm3bOZUqwah+40GKtwpTlUEPiiIRnH8lWVAR6I8= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=h6ECUkMAsZuAJh9w/7KIGkgiPMMgok4GjyNEBG85b+v7hbo1NqHKZetW5pNxUlcDQiAGTq2+e9EBtO+ip3ZTSVC3xlTzICiyVsnR/XQEIIICXBRgoO0oylyqzPfyO8W5/vmsryT4XIBHl4tN7ibXyIZm1TF1ZObQv4ZlO31oPDA=; Message-ID: <889006.52406.qm@web51407.mail.re2.yahoo.com> X-YMail-OSG: 5kyMiVQVM1m0RRN6H1rNbhErhd5Bfacg3M2AjZ0txfdHwX6qR4K1UMYwhmArvK5gVKi59QJHdwe3Pe4osI.Tqj.71TtcZFxhOPn54Sl0YL9gCA4r7Lc8jWNgpktJiz0JzxlOfUwX1Q.4VOP2PGcSU3YTzpAcW..NYC5_hjpdFiLNTXKXmxh53XX9ZNF8I0wv0z02GxybpnKuU5VxfJcxGe00MqcQfnoJ2M_OrH9qdHtLvucCXlKFVHo4pe.o4ilf8EdKfhilGsPuLXUmfwL5haLLQKJhkvtAX9MIQO1GumD8.jkzL3mw Received: from [70.116.12.67] by web51407.mail.re2.yahoo.com via HTTP; Tue, 15 Sep 2009 19:56:48 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Tue, 15 Sep 2009 19:56:48 -0700 (PDT) From: Thomas Anderson Subject: Re: maximum size of packets from client to server To: ietf-ssh@NetBSD.org 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 der Mouse wrote: >> The SSH spec doesn't really explain the semantics of the server's >> response to the channel open command, in particular whether the >> returned data size parameters are merely a confirmation of the >> client's requested values or whether the server is allowed to >> further modify them to suit its own requirements (or perhaps one is >> for send and the other for receive?). > > One thing I would like to see clarified here but haven't seen mentioned > is what level the max packet size applies at. Is it the max data > payload of a CHANNEL_DATA (or CHANNEL_EXTENDED_DATA) packet, the max > size of a CHANNEL_DATA (or ...) packet in cleartext form, the max size > of such a packet with encryption and padding, what? I actually mentioned that in my third email as something else I'd like to see clarification on. The other thing I mentioned in that email as being unclear to me was this: > On this same subject, here's something else I think could use > clarification. RFC4254#section-5.1 states that the "maximum packet > size" refers to the "maximum size of an individual data packet". This > raises the question... what qualifies as a data packet. Does > SSH_MSG_CHANNEL_REQUEST qualify as a data packet, for example? Often, > they wouldn't, but if the request type is "exec", a > SSH_MSG_CHANNEL_REQUEST could easily exceed "maximum packet size". From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 15 21:51:48 2009 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 314363A6887 for ; Tue, 15 Sep 2009 21:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 66R6ElH4owII for ; Tue, 15 Sep 2009 21:51:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 278C13A683F for ; Tue, 15 Sep 2009 21:51:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EE78F63B156; Wed, 16 Sep 2009 04:52:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id E270063B154 for ; Wed, 16 Sep 2009 04:52:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 905C7416E8B; Wed, 16 Sep 2009 16:52:25 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-NFezxTXL42; Wed, 16 Sep 2009 16:52:25 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B3F2F416E92; Wed, 16 Sep 2009 16:52:24 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DC76F19EC0BC; Wed, 16 Sep 2009 16:52:23 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1MnmVD-0003Dx-P7; Wed, 16 Sep 2009 16:52:23 +1200 From: Peter Gutmann To: ietf-ssh2@denisbider.com, ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <4CB1BC9530374019A3A175E67010384A@element> Message-Id: Date: Wed, 16 Sep 2009 16:52:23 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "denis bider (Bitvise)" writes: >The "number of different people" that you refer to is 1. I was referring to an earlier email in the thread where someone made a comment about three different interpretations from three different people. Unfortunately the list doesn't appear to be archived anywhere (it's not listed on the NetBSD lists index) so I can't check the exact wording. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 16 04:36:33 2009 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 667803A68A9 for ; Wed, 16 Sep 2009 04:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.205 X-Spam-Level: X-Spam-Status: No, score=-9.205 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 UeGk8m6OADsT for ; Wed, 16 Sep 2009 04:36:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5F7E63A66B4 for ; Wed, 16 Sep 2009 04:36:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6A7C163B171; Wed, 16 Sep 2009 11:37:13 +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 B6A6F63B129 for ; Wed, 16 Sep 2009 11:37:11 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA18280; Wed, 16 Sep 2009 07:37:10 -0400 (EDT) From: der Mouse Message-Id: <200909161137.HAA18280@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. Date: Wed, 16 Sep 2009 07:20:08 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> The "number of different people" that you refer to is 1. > I was referring to an earlier email in the thread where someone made > a comment about three different interpretations from three different > people. That would have been me. It's recent enough to still be in my mail history trail; here's the quote: | I thought it was obvious, but here we have three people thinking of | three different interpretations, so it clearly isn't as obvious as I | thought. The three were: - Thomas, earlier in this thread, saying "I thought those extra fields were for confirmation purposes and didn't give it a second thought". (You mentioned this one too.) - You, speculating that "the server is allowed to further modify them to suit its own requirements". - Me, taking the OPEN_CONFIRMATION values as being the values for the confirmer->opener direction, with the values in the OPEN packet being just for the opener->confirmer direction. And, denis, even if, as you wrote, "Thomas is a newbie who understood the concept the instant it was explained", Peter's point that the spec is unclear is still valid: the spec's wording has provoked three incompatible interpretations from three different people, indicating (to me at least) that the spec is unclear enough to need fixing. How those people react to having other interpretations presented to them is irrelevant to this point. /~\ 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 Sep 16 04:50:37 2009 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 126083A6925 for ; Wed, 16 Sep 2009 04:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.335 X-Spam-Level: X-Spam-Status: No, score=-9.335 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 cDAF99khgdWa for ; Wed, 16 Sep 2009 04:50:36 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id DD0353A68E6 for ; Wed, 16 Sep 2009 04:50:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1EA4E63B17A; Wed, 16 Sep 2009 11:51:19 +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 7348963B129 for ; Wed, 16 Sep 2009 11:51:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id HAA18361; Wed, 16 Sep 2009 07:51:16 -0400 (EDT) From: der Mouse Message-Id: <200909161151.HAA18361@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. Date: Wed, 16 Sep 2009 07:38:44 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <889006.52406.qm@web51407.mail.re2.yahoo.com> References: <889006.52406.qm@web51407.mail.re2.yahoo.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> One thing I would like to see clarified here but haven't seen >> mentioned is what level the max packet size applies at. > I actually mentioned that in my third email as something else I'd > like to see clarification on. Sorry, I must have missed your mention. Since people are quoting the comments from their code, here's the relevant comment from mine: /* * This value is what we put in the "maximum packet size" field of * CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages we generate. * This is documented as * The 'maximum packet size' specifies the maximum size of an * individual data packet that can be sent to the sender. * There is disagreement over exactly what this means. It seems to me * that this means "the maximum size of a CHANNEL_DATA or * CHANNEL_EXTENDED_DATA message", but at least two other * implementations take it to mean "the maximum size of a CHANNEL_DATA * or CHANNEL_EXTENDED_DATA data payload". When I put * SSH_MAX_PAYLOAD_LEN in here, I would relatively routinely get * crashes in which the remote end overran my specified maximum size * by 9 bytes (ie, the difference between the size of a CHANNEL_DATA * packet and the size of its data payload). While I still think my * reading is right, the wording is now frozen (and thus won't change * even if it turns out I'm right) and other implementations aren't * going to change their deployed base overnight even if they agree * with me today. So we allow some slop. It's tempting to produce * nag messages if we detect a peer treating this value as a max data * _payload_ size instead of a max data _packet_ size, in an attempt * to get people to fix their other implementations, but for now I'm * holding off on that; I'm going to try to get this nailed down on * the WG list first. * * We take the opposite interpretation when handling maxsend values * from incoming CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages, * taking them as maximum data packet size rather than maximum data * payload size. This is not because we're twisted (though that might * be a defensible position :), but because we're conservative; doing * this causes us to use a lower value, making it harder to overrun * other implementations. (Besides, it's what the spec specifies. :) * (Actually, we do this only if the max-packet value is >13; * otherwise, when we subtract 13, the result would be zero or * negative. Anyone specifying a value that small *must* be treating * it as a max payload size rather than a max total packet size - or * severely buggy, I suppose.) * * 13 is the difference between a CHANNEL_EXTENDED_DATA packet size and * its data payload size. This is the largest overhead we have to * deal with; for CHANNEL_DATA packets, the overhead is only 9, but * there's only one value, so we have to deduct for the largest packet * overhead. */ #define MAX_PACKET_SIZE_VALUE (SSH_MAX_PAYLOAD_LEN-13) I think the data payload size is probably what the author of that part of the spec had in mind, but it's not what the language actually says. /~\ 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 Sep 16 07:54:03 2009 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 890C93A6986 for ; Wed, 16 Sep 2009 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619, STOX_REPLY_TYPE=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 HTHcKy10BFGf for ; Wed, 16 Sep 2009 07:54:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BC4793A6AC1 for ; Wed, 16 Sep 2009 07:54:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 44F9963B17E; Wed, 16 Sep 2009 14:54:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from skroderider.denisbider.com (skroderider.denisbider.com [66.197.186.181]) (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 2E28D63B183 for ; Wed, 16 Sep 2009 14:54:42 +0000 (UTC) Received: from element ([209.59.72.219]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Wed, 16 Sep 2009 10:54:30 -0400 Message-ID: <3758A4F85CF44BC5B5387D70EE606287@element> From: "denis bider \(Bitvise\)" To: References: <200909161137.HAA18280@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200909161137.HAA18280@Sparkle.Rodents-Montreal.ORG> Subject: Re: maximum size of packets from client to server Date: Wed, 16 Sep 2009 10:54:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > And, denis, even if, as you wrote, "Thomas is a newbie who > understood the concept the instant it was explained", Peter's > point that the spec is unclear is still valid: the spec's wording > has provoked three incompatible interpretations from three > different people, indicating (to me at least) that the spec is > unclear enough to need fixing. Yes, I agree. The spec needs to be clarified on this point. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 16 10:52:01 2009 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 1C3093A6A83 for ; Wed, 16 Sep 2009 10:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 heXwXb+m-Rhx for ; Wed, 16 Sep 2009 10:52:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4ADF93A6B90 for ; Wed, 16 Sep 2009 10:52:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8FE1F63B18D; Wed, 16 Sep 2009 17:52:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from web51405.mail.re2.yahoo.com (web51405.mail.re2.yahoo.com [206.190.38.184]) by mail.netbsd.org (Postfix) with SMTP id 0192663B146 for ; Wed, 16 Sep 2009 17:52:42 +0000 (UTC) Received: (qmail 36593 invoked by uid 60001); 16 Sep 2009 16:06:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253117162; bh=dMjmMP4saJy2OFdpVX0YO98Wh7S5Pc5ue9m5FCGDxmE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NBPzhleMziPgDOh6MD3NQtOydB3RGiSql/lqfQVFV/XZpZ8stuWB5Mu1AYOLfQqt9ji8UUR9hFQwgQIgusKllPaRJ3ioWc3yGpb0if0HhW/exx6Zgr5kqsO4TfozFLjjkVVfi8+RQt3wJZdv6UnretjdDF4ssJqLOGDXAKvl4Bk= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=g4QCTU/bBlzdnNk/Yuq7Q04SCXMudwpSKQEoONnDYbl5l0SWqJtcvZ1z7V7U4IpFHaVHQKsazI+gWtNeKwZBtHolazMLx7v1NQQvpp6cLWAFUk7ziA6BY/1ANijgVkBnB5L2QvgpYXiihd4SbJLB6ZrZOk5+gZkYda9t0+ZZQSM=; Message-ID: <383152.36408.qm@web51405.mail.re2.yahoo.com> X-YMail-OSG: YYoN6k0VM1my5goDwXNTYxQ2no1uZg.o_qcjDHTfnyuVgsIqc6H2BHBqpSysQNPyhZEOd8yI5IGo1fMg2lSKazBgZY6PTf3UVn.47WsCjoNHQr.GaJB6OJYx0l4TcZNlupyy6H_9IH0C7zv85dR9XUV7QMgQWMA4bC4byHGWw427qMCeB4yRlmLzqxSxcWTP10r4l9mq07UptBVWTFhUpFw2rY8OHC.TWqpa40I1CzY6pbbEOEjZTS3EmRfUPWtVfdHMmNoTr3HGO5reIGnq5zH7.wJAvNxXOnxHzVMiY2wH3kUjawUAzGjnlg3lmPgoaji4jc0nMgKCI4Pm64vZ Received: from [129.116.66.226] by web51405.mail.re2.yahoo.com via HTTP; Wed, 16 Sep 2009 09:06:01 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Wed, 16 Sep 2009 09:06:01 -0700 (PDT) From: Thomas Anderson Subject: Re: maximum size of packets from client to server To: ietf-ssh@NetBSD.org 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 Peter Gutmann wrote: > > Unfortunately the list doesn't appear to be archived anywhere (it's not listed > on the NetBSD lists index) so I can't check the exact wording. There's this: ftp://ftp.ietf.org/ietf-mail-archive/secsh/2009-09.mail From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 16 10:54:42 2009 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 6D0493A6A7B for ; Wed, 16 Sep 2009 10:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_05=-1.11] 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 Cb5C1WRcZeF2 for ; Wed, 16 Sep 2009 10:54:41 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 66AD03A6B09 for ; Wed, 16 Sep 2009 10:54:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0DB6563B383; Wed, 16 Sep 2009 17:55:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from web51410.mail.re2.yahoo.com (web51410.mail.re2.yahoo.com [206.190.38.189]) by mail.netbsd.org (Postfix) with SMTP id 8689763B19A for ; Wed, 16 Sep 2009 17:55:27 +0000 (UTC) Received: (qmail 11017 invoked by uid 60001); 16 Sep 2009 16:08:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253117325; bh=cDRT8B12a2kdLO6UZW2ii6Pvhv8Q0MxM6yNGo4kHTKk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=0WvVgxTQPsufsxyYwru98WdhoVnEyZV9EaODSGFku0G3TL61IHto3pfAwTQnUT6nr1yBLbYF3Wof7ab/5XPNsa7MUUdA1DFt7n1aDOcH6ojLrwxxkSPftvUhxEQEJsc+LNlkjlV96oZnfd3lafXuWazo3T5R23AD4kSetao0uH8= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=QWSKExJeQiz8v2RkkSmOh7EJl3TCMIMOQ+/5TL8HyyZVeam0Ee47w0aRepdelpqFuDDMByRicTGTPyscNPSJJ87AqNShyW/iQbTNr7LjWcsN9CUF2VNoOF3X1IGw2JquqFvnAaaENxcfiUNA8JJokNFKlPIF0yRlL3pDLws8YDs=; Message-ID: <851476.10338.qm@web51410.mail.re2.yahoo.com> X-YMail-OSG: VcKp4RcVM1k3TV9GOCRcOo96iPRvrbP2iYz84b7huWVMFJwYPoQTKTHciv7jcY8rzvWTxM0YcuO6zVtNzu_5mkqh09jfCFyzRb17lSRO47MRuwam68mZv2c0etrUXBHWUPkBSGBhBzL4wDAyEOiJgTW77HcS4Sn1ATFcE6J6B9Abyj2q37L6I20.vhqLMr3NGdblVIBbP9dV_g60bTXw.y9lWaqGL5Jds5hTi2e8WbrnGQMhXxaDzRp31WJhuHKmC_xjI7avwSlKMY8jiPJxFz0c8xgWxgJwoG8tw_betSlXtC8srvCxD5qH03BE_9NIHNOIrA47WXR1oQhfo1s- Received: from [129.116.66.226] by web51410.mail.re2.yahoo.com via HTTP; Wed, 16 Sep 2009 09:08:45 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Wed, 16 Sep 2009 09:08:45 -0700 (PDT) From: Thomas Anderson Subject: Re: maximum size of packets from client to server To: ietf-ssh@NetBSD.org 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 der Mouse wrote: > > While I still think my reading is right, the wording is now frozen > (and thus won't change even if it turns out I'm right) and other > implementations aren't going to change their deployed base overnight > even if they agree with me today. What determines whether or not an RFC is frozen? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Sep 16 11:35:44 2009 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 B09DF3A6842 for ; Wed, 16 Sep 2009 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.428 X-Spam-Level: X-Spam-Status: No, score=-9.428 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 zMqMe4JmyBvx for ; Wed, 16 Sep 2009 11:35:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CAB5C3A6966 for ; Wed, 16 Sep 2009 11:35:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F303363B3C4; Wed, 16 Sep 2009 18:36: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 9776663B3C3 for ; Wed, 16 Sep 2009 18:36:29 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA20376; Wed, 16 Sep 2009 14:36:28 -0400 (EDT) From: der Mouse Message-Id: <200909161836.OAA20376@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. Date: Wed, 16 Sep 2009 14:34:34 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: maximum size of packets from client to server In-Reply-To: <851476.10338.qm@web51410.mail.re2.yahoo.com> References: <851476.10338.qm@web51410.mail.re2.yahoo.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> While I still think my reading is right, the wording is now frozen >> (and thus [...]) [...] > What determines whether or not an RFC is frozen? As I understand it (an important qualification here - I may well be wrong on this), by the time an RFC makes it past the RFC editor and is published, it is frozen; if it needs changes after that, a new RFC must be generated and published. /~\ 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 Sep 16 12:45:46 2009 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 64A1C3A6A5D for ; Wed, 16 Sep 2009 12:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] 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 2d6sZP1ITUz6 for ; Wed, 16 Sep 2009 12:45:45 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6A28F3A6A9D for ; Wed, 16 Sep 2009 12:45:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B89FD63B172; Wed, 16 Sep 2009 19:46:28 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.srv.cs.cmu.edu", Issuer "CS CA Web 2" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9DD8F63B117 for ; Wed, 16 Sep 2009 19:46:27 +0000 (UTC) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n8GIPxQ5026938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Sep 2009 14:26:00 -0400 (EDT) Date: Wed, 16 Sep 2009 14:25:59 -0400 From: Jeffrey Hutzelman To: Thomas Anderson , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: maximum size of packets from client to server Message-ID: <6AC50BEFA4B71ADA1690B4F7@atlantis.pc.cs.cmu.edu> In-Reply-To: <851476.10338.qm@web51410.mail.re2.yahoo.com> References: <851476.10338.qm@web51410.mail.re2.yahoo.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.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --On Wednesday, September 16, 2009 09:08:45 AM -0700 Thomas Anderson wrote: > der Mouse wrote: >> >> While I still think my reading is right, the wording is now frozen >> (and thus won't change even if it turns out I'm right) and other >> implementations aren't going to change their deployed base overnight >> even if they agree with me today. > > What determines whether or not an RFC is frozen? An RFC is immutable once published. The RFC Editor maintains a list of errata on published RFC's, at ; those generally include editorial and technical errors discovered after publication. It is possible to update a specification by publishing a new version. However, it seems unlikely that that will happen in this case, unless the SSH specifications are being updated for other reasons. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 05:38:31 2009 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 D16563A67A7 for ; Mon, 21 Sep 2009 05:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 pUemf693yFPP for ; Mon, 21 Sep 2009 05:38:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id EF0FD28C13E for ; Mon, 21 Sep 2009 05:38:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AB44363B115; Mon, 21 Sep 2009 12:39:22 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 06F7763B10C for ; Mon, 21 Sep 2009 12:39:20 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 5C40C40018; Mon, 21 Sep 2009 14:38:35 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 51E0540056; Mon, 21 Sep 2009 14:38:35 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 9F24940018; Mon, 21 Sep 2009 14:38:34 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8LCdGS5028945; Mon, 21 Sep 2009 14:39:16 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8LCdE0g028944; Mon, 21 Sep 2009 14:39:14 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 21 Sep 2009 14:39:14 +0200 In-Reply-To: (Peter Gutmann's message of "Wed, 16 Apr 2008 01:36:18 +1200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > It's 3072 bits, with a corresponding subgroup size of 256 bits (I guess they > were nervous about SHA-512 and so stopped there :-). Now I've looked (fairly quickly) through FIPS-186-3 (http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf). It specifies four variants for different key sizes. L is the bitsize of p, and N is the bitsize of q and also the digest size (in bits) of the underlying hash function. L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 As far as I understand, intermediate keysizes are not allowed at all (in contrast to the original dsa, which allowed keysizes 512, 576, 640,..., 1024 with 64 bit increments. The hash function to use is *not* specified explicitly, it is only stated that it should be an "approved" hash function. For N = 160, one ought to use sha1 (as this ought to be intended to be backwards compatible). For N = 224, one might use either SHA-224 or truncated SHA-256 (the way SHA-224 is constructed, the only difference between these two alternatives is the initial state), and for N = 256, one ought to use SHA-256. Before implementing larger DSA, I'd like to see a specification that also specifies explicitly the hash function to use, and which provides some test vectors. Where should I look? Implementation-wise, I think I'd prefer to first parametrize dsa with respect to the hash function, e.g., define "dsa-sha256" to use SHA-256, which implies a value for N above, and then be somewhat more liberal when it comes to allowed key size L. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 10:22:10 2009 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 949883A68A1 for ; Mon, 21 Sep 2009 10:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 IKZ+3Fy30EkN for ; Mon, 21 Sep 2009 10:22:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C22FE28C1E6 for ; Mon, 21 Sep 2009 10:22:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D4E8E63B174; Mon, 21 Sep 2009 17:23:02 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 426FC63B101 for ; Mon, 21 Sep 2009 17:23:00 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1602540011; Mon, 21 Sep 2009 19:22:16 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 09B2E4005C; Mon, 21 Sep 2009 19:22:16 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id E695A40011; Mon, 21 Sep 2009 19:22:15 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8LHMwaG011707; Mon, 21 Sep 2009 19:22:58 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8LHMu2B011706; Mon, 21 Sep 2009 19:22:56 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: James Blaisdell Cc: Peter Gutmann , "ietf-ssh@NetBSD.org" Subject: Re: SSH non-compliance with FIPS 186 References: <50DADDE6B33B1B47904E685AAFDC18241A92E6E497@yugi.mocana.local> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 21 Sep 2009 19:22:55 +0200 In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A92E6E497@yugi.mocana.local> (James Blaisdell's message of "Mon, 21 Sep 2009 09:45:18 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list James Blaisdell writes: > I started looking into this as well. FIPS 140-2 refers to this as > "DSA2," Where, more precisely? FIPS 140-2 "Security Requirements for Cryptographic Modules" doesn't seem to mention dsa at all. Is it in one of the annexes? > I believe a new draft/RFC is required for ssh-dsa2-* > (ssh-dsa2-160/224/256/385/512) algorithms. For me, the first step is to find a *complete* and authoritative specification for these dsa variants, preferably including test vectors. I'd like to have the general signature algorithm done correctly, before worrying too much about how to use it in ssh. For ssh, initially, I could implement it under a name like dsa-sha256@lysator.liu.se, next we'd have to agree on the details, and then arrange to allocate an official name and document it as an informational RFC, or something like that. Are there any other Internet standards that use these updated DSA variants? /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 10:44:55 2009 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 1D5D53A68F6 for ; Mon, 21 Sep 2009 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 MCLTqfnzlSyS for ; Mon, 21 Sep 2009 10:44:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3CDA43A6839 for ; Mon, 21 Sep 2009 10:44:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F35163B238; Mon, 21 Sep 2009 17:45:45 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from email.mocana.com (email.mocana.com [67.102.231.118]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "email.mocana.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 636E563B101 for ; Mon, 21 Sep 2009 17:45:43 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Mon, 21 Sep 2009 09:43:38 -0700 From: James Blaisdell To: =?iso-8859-1?Q?Niels_M=F6ller?= , Peter Gutmann CC: "ietf-ssh@NetBSD.org" Date: Mon, 21 Sep 2009 09:45:18 -0700 Subject: RE: SSH non-compliance with FIPS 186 Thread-Topic: SSH non-compliance with FIPS 186 Thread-Index: Aco6uFdmD15j16ZMQGG9g8TUPzPN6wAIWzqA Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A92E6E497@yugi.mocana.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, I started looking into this as well. FIPS 140-2 refers to this as "DSA2," = same underlying DSA algorithm operations (key generation, sign, verify, etc= ) can use a stronger hash algorithm than SHA1. As a result SSH is incompat= ible with these new "DSA2" algorithms. I believe a new draft/RFC is requir= ed for ssh-dsa2-* (ssh-dsa2-160/224/256/385/512) algorithms. =20 Thank you, James -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Niels M=F6ller Sent: Monday, September 21, 2009 5:39 AM To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > It's 3072 bits, with a corresponding subgroup size of 256 bits (I guess t= hey > were nervous about SHA-512 and so stopped there :-). Now I've looked (fairly quickly) through FIPS-186-3 (http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf). It specifies four variants for different key sizes. L is the bitsize of p, and N is the bitsize of q and also the digest size (in bits) of the underlying hash function. L =3D 1024, N =3D 160 L =3D 2048, N =3D 224 L =3D 2048, N =3D 256 L =3D 3072, N =3D 256 As far as I understand, intermediate keysizes are not allowed at all (in contrast to the original dsa, which allowed keysizes 512, 576, 640,..., 1024 with 64 bit increments. The hash function to use is *not* specified explicitly, it is only stated that it should be an "approved" hash function. For N =3D 160, one ought to use sha1 (as this ought to be intended to be backwards compatible). For N =3D 224, one might use either SHA-224 or truncated SHA-256 (the way SHA-224 is constructed, the only difference between these two alternatives is the initial state), and for N =3D 256, one ought to use SHA-256. Before implementing larger DSA, I'd like to see a specification that also specifies explicitly the hash function to use, and which provides some test vectors. Where should I look? Implementation-wise, I think I'd prefer to first parametrize dsa with respect to the hash function, e.g., define "dsa-sha256" to use SHA-256, which implies a value for N above, and then be somewhat more liberal when it comes to allowed key size L. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 10:45:08 2009 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 4F8703A6945 for ; Mon, 21 Sep 2009 10:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 o88ABmPHZ1Ht for ; Mon, 21 Sep 2009 10:45:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3DF183A6782 for ; Mon, 21 Sep 2009 10:45:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8884963B131; Mon, 21 Sep 2009 17:46:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from email.mocana.com (email.mocana.com [67.102.231.118]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "email.mocana.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 46FE163B101 for ; Mon, 21 Sep 2009 17:46:03 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Mon, 21 Sep 2009 10:29:44 -0700 From: James Blaisdell To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Peter Gutmann , "ietf-ssh@NetBSD.org" Date: Mon, 21 Sep 2009 10:31:24 -0700 Subject: RE: SSH non-compliance with FIPS 186 Thread-Topic: SSH non-compliance with FIPS 186 Thread-Index: Aco63/NBau+dgVTWR9ut5l5uK97JEwAAFGKw Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A92E6E49E@yugi.mocana.local> References: <50DADDE6B33B1B47904E685AAFDC18241A92E6E497@yugi.mocana.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, Please see NIST 186-3 (June 2009): http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf After cursory review, it appears trivial to convert DSA1 --> DSA2, but DSA2= is incompatible with ssh-dsa. =20 Thank you, James -----Original Message----- From: Niels M=F6ller [mailto:nisse@lysator.liu.se]=20 Sent: Monday, September 21, 2009 10:23 AM To: James Blaisdell Cc: Peter Gutmann; ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 James Blaisdell writes: > I started looking into this as well. FIPS 140-2 refers to this as > "DSA2," Where, more precisely? FIPS 140-2 "Security Requirements for Cryptographic Modules" doesn't seem to mention dsa at all. Is it in one of the annexes? > I believe a new draft/RFC is required for ssh-dsa2-* > (ssh-dsa2-160/224/256/385/512) algorithms. For me, the first step is to find a *complete* and authoritative specification for these dsa variants, preferably including test vectors. I'd like to have the general signature algorithm done correctly, before worrying too much about how to use it in ssh. For ssh, initially, I could implement it under a name like dsa-sha256@lysator.liu.se, next we'd have to agree on the details, and then arrange to allocate an official name and document it as an informational RFC, or something like that. Are there any other Internet standards that use these updated DSA variants? /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 11:06:30 2009 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 DB2943A6AC7 for ; Mon, 21 Sep 2009 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 gvJ8W7kPNnfk for ; Mon, 21 Sep 2009 11:06:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BC92C3A6AC8 for ; Mon, 21 Sep 2009 11:06:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7AACF63B125; Mon, 21 Sep 2009 18:07:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from email.mocana.com (email.mocana.com [67.102.231.118]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "email.mocana.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id AF13463B2BE for ; Mon, 21 Sep 2009 18:07:12 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Mon, 21 Sep 2009 11:05:30 -0700 From: James Blaisdell To: =?iso-8859-1?Q?Niels_M=F6ller?= CC: Peter Gutmann , "ietf-ssh@NetBSD.org" Date: Mon, 21 Sep 2009 11:07:11 -0700 Subject: RE: SSH non-compliance with FIPS 186 Thread-Topic: SSH non-compliance with FIPS 186 Thread-Index: Aco63/NBau+dgVTWR9ut5l5uK97JEwABeLjw Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A92E6E4A6@yugi.mocana.local> References: <50DADDE6B33B1B47904E685AAFDC18241A92E6E497@yugi.mocana.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Niels, Sorry for my short reply. I stumbled across DSA2 while starting new round = of FIPS 140-2 testing. It's not a requirement for FIPS, but simply yet ano= ther algorithm which is FIPS-able. The FIPS documentation refers to it as = DSA2, which sounds good to me, although web searches revealed almost nothin= g, but the documentation did refer to NIST 186-3. =20 Your idea on unique name space is great, and I wish this was practiced more= especially for drafts. I might be up for implementing this in a couple of= weeks, if you want to do any interop testing. =20 Thanks, James -----Original Message----- From: Niels M=F6ller [mailto:nisse@lysator.liu.se]=20 Sent: Monday, September 21, 2009 10:23 AM To: James Blaisdell Cc: Peter Gutmann; ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 James Blaisdell writes: > I started looking into this as well. FIPS 140-2 refers to this as > "DSA2," Where, more precisely? FIPS 140-2 "Security Requirements for Cryptographic Modules" doesn't seem to mention dsa at all. Is it in one of the annexes? > I believe a new draft/RFC is required for ssh-dsa2-* > (ssh-dsa2-160/224/256/385/512) algorithms. For me, the first step is to find a *complete* and authoritative specification for these dsa variants, preferably including test vectors. I'd like to have the general signature algorithm done correctly, before worrying too much about how to use it in ssh. For ssh, initially, I could implement it under a name like dsa-sha256@lysator.liu.se, next we'd have to agree on the details, and then arrange to allocate an official name and document it as an informational RFC, or something like that. Are there any other Internet standards that use these updated DSA variants? /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 23:11:51 2009 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 DB2883A68E3 for ; Mon, 21 Sep 2009 23:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 LNnnEX2iZCaL for ; Mon, 21 Sep 2009 23:11:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BDBDF3A68C7 for ; Mon, 21 Sep 2009 23:11:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E184D63B178; Tue, 22 Sep 2009 06:12:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id A2E0363B169 for ; Tue, 22 Sep 2009 06:12:39 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4AC7D41DBDB; Tue, 22 Sep 2009 18:12:38 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRCuqLJemfY5; Tue, 22 Sep 2009 18:12:38 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2B96241CCC5; Tue, 22 Sep 2009 18:12:37 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3F8DE19EC0DA; Tue, 22 Sep 2009 18:12:37 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Mpyc9-00066b-4S; Tue, 22 Sep 2009 18:12:37 +1200 From: Peter Gutmann To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: SSH non-compliance with FIPS 186 Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Tue, 22 Sep 2009 18:12:37 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >Before implementing larger DSA, I'd like to see a specification that also >specifies explicitly the hash function to use, and which provides some test >vectors. Where should I look? The only test vectors that I know of were generated by one of the OpenPGP guys a few years ago (one of the, um, "features" of DSA2 is that since it rarely gets used there's not much scope for interop problems :-), you can get them from http://www.jabberwocky.com/openpgp/dsa2.tar.gz. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 21 23:17:31 2009 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 02A1E3A67D9 for ; Mon, 21 Sep 2009 23:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 yimoUiwTZAzd for ; Mon, 21 Sep 2009 23:17:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CD3D63A6783 for ; Mon, 21 Sep 2009 23:17:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F0C4563B146; Tue, 22 Sep 2009 06:18:29 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mail.netbsd.org (Postfix) with ESMTP id 6634563B111 for ; Tue, 22 Sep 2009 06:18:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 706C717381E; Tue, 22 Sep 2009 18:18:26 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ay6GXCfrJPO; Tue, 22 Sep 2009 18:18:26 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4DDA61701EE; Tue, 22 Sep 2009 18:18:24 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BB8FD19EC0DA; Tue, 22 Sep 2009 18:18:23 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Mpyhj-0006c6-Jt; Tue, 22 Sep 2009 18:18:23 +1200 From: Peter Gutmann To: JBlaisdell@mocana.com, nisse@lysator.liu.se Subject: Re: SSH non-compliance with FIPS 186 Cc: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Tue, 22 Sep 2009 18:18:23 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >Are there any other Internet standards that use these updated DSA variants? OpenPGP sort of does, in the sense that their use is covered in the RFC, however the OpenPGP RFC has historically adopted a whole range of bleeding- edge algorithms that it turned out no-one was really interested in, which is why I used the phrase "covered in the RFC" rather than "used". For example GPG will verify DSA2 sigs but won't generate them unless you explicitly feed it a special command-line option telling it to use DSA2. No idea what other implementations do. With a bit more hindsight now that some time has passed, it may be easier to just deprecate DSA rather than trying to specify usage rules for something that no-one seems to be using. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 22 01:02:29 2009 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 1026A3A685C for ; Tue, 22 Sep 2009 01:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 rIWRsYC2LcNg for ; Tue, 22 Sep 2009 01:02:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 938ED3A6986 for ; Tue, 22 Sep 2009 01:02:27 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A95FA63B157; Tue, 22 Sep 2009 08:03:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 E05BA63B2C9 for ; Tue, 22 Sep 2009 08:03:20 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A0B984000A; Tue, 22 Sep 2009 10:02:35 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 9552B40026; Tue, 22 Sep 2009 10:02:35 +0200 (CEST) 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)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 2F8AA4000A; Tue, 22 Sep 2009 10:02:35 +0200 (CEST) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n8M83HFA022839; Tue, 22 Sep 2009 10:03:17 +0200 (MEST) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.13.8+Sun/8.13.8/Submit) id n8M83FAd022832; Tue, 22 Sep 2009 10:03:15 +0200 (MEST) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Peter Gutmann Cc: JBlaisdell@mocana.com, ietf-ssh@NetBSD.org Subject: Re: SSH non-compliance with FIPS 186 References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Tue, 22 Sep 2009 10:03:15 +0200 In-Reply-To: (Peter Gutmann's message of "Tue, 22 Sep 2009 18:18:23 +1200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Peter Gutmann writes: > With a bit more hindsight now that some time has passed, it may be easier to > just deprecate DSA rather than trying to specify usage rules for something > that no-one seems to be using. I'd recommend anybody to use RSA rather than DSA, since it's obvious that you can use as large keys as you like, and you avoid the hassle with the security of signature operation depending on the randomness generator.[1] Nevertheless, I see a couple of reasons to have larger DSA in the ssh protocol. 1. Not that I expect RSA to be broken anytime soon, but I think it's good practice to have two different and well-respected algorithms that are supported by most implementations. 2. In practice, people seem to be using large out-of spec DSA keys with ssh-dss. Probably not realizing that the small fixed size of q also limits the security. 3. The security for the largest key sizes in the original (as currently supported in ssh) dsa algorithm, 1024/160, seem to be on the borderline of being too weak today. Hence, if we want to continue to support DSA, a spec that uses larger keys in a proper way seems like a good thing. As a practical matter, if we want to have larger dsa, I'd suggest adopting "dsa-sha256", specified to a use 256-bit q, SHA-256, and with more or less arbitrary size of p (but recommended in the range 2048 to 3072). > The only test vectors that I know of were generated by one of the OpenPGP guys > a few years ago (one of the, um, "features" of DSA2 is that since it rarely > gets used there's not much scope for interop problems :-), you can get them > from http://www.jabberwocky.com/openpgp/dsa2.tar.gz. Thanks. I'm surprised and disappointed if NIST really haven't published any official test vectors. I thought everybody agreed that that's an essential part of any specification for a cryptographic algorithm. [1] I think putty uses a clever trick to avoid that dependency, by generating the "random" number involved in DSA signing using hashing of the secret key and the message being signed. Probably difficult to prove any security, but it boils down to a problem somewhat like "give the attacker both H(x) and g^x mod p, and let the attacker try to find x". I'd expect that knowledge of H(x) won't be of much help in the discrete logarithm problem and vice versa, but that's just my gut feeling. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 22 01:49:52 2009 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 0C6213A68F0 for ; Tue, 22 Sep 2009 01:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 wqT7uw1Njh1m for ; Tue, 22 Sep 2009 01:49:49 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 78D7F3A6837 for ; Tue, 22 Sep 2009 01:49:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A722863B19B; Tue, 22 Sep 2009 08:50:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mail.netbsd.org (Postfix) with ESMTP id 187BA63B123 for ; Tue, 22 Sep 2009 08:50:41 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2BFC541CDA1; Tue, 22 Sep 2009 20:50:37 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkY6nmAK7--5; Tue, 22 Sep 2009 20:50:37 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A79F941CD96; Tue, 22 Sep 2009 20:50:36 +1200 (NZST) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 402D519EC0DB; Tue, 22 Sep 2009 20:50:36 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Mq152-0006Bi-3s; Tue, 22 Sep 2009 20:50:36 +1200 From: Peter Gutmann To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: SSH non-compliance with FIPS 186 Cc: ietf-ssh@NetBSD.org, JBlaisdell@mocana.com In-Reply-To: Message-Id: Date: Tue, 22 Sep 2009 20:50:36 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >people seem to be using large out-of spec DSA keys with ssh-dss. Ahh, good point. The precise reason why GPG doesn't support DSA2 by default is out of concern over users who want to make a fashion statement with stupidly large keys that nothing on the receiving end will be able to verify, but in the case of SSH since it's negotiated interactively this won't be such a problem since the other side can simply choose to decline that option. >As a practical matter, if we want to have larger dsa, I'd suggest adopting >"dsa-sha256", specified to a use 256-bit q, SHA-256, and with more or less >arbitrary size of p (but recommended in the range 2048 to 3072). Yup, I'd agree with choosing that as the universal-to-support standard, the larger hashes get a bit messy on 32-bit architectures, the combination of SHA-256 with 2K-3K keys is a nice balance. >I'm surprised and disappointed if NIST really haven't published any official >test vectors. I thought everybody agreed that that's an essential part of any >specification for a cryptographic algorithm. They tend to lag the drafts by a long, long time, so you have to scrape them together wherever you can find them. Usually you end up with pulling something out of whatever the latest version of the CAVS software is on the assumption that it must be OK. Testing against a consensual hallucination seems to be a somewhat unsound practice though. >I think putty uses a clever trick to avoid that dependency, by generating the >"random" number involved in DSA signing using hashing of the secret key and >the message being signed. AFAIK this was first done by the commercial PGP some years ago. It works a bit better for that because what's being hashed is also encrypted, so an attacker won't have access to the preimage. Peter. From lroberts@triton.edu Wed Sep 30 06:21:02 2009 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 C50973A6905 for ; Wed, 30 Sep 2009 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.85 X-Spam-Level: ** X-Spam-Status: No, score=2.85 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_99=3.5, J_CHICKENPOX_74=0.6] 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 RbRZUOSjC4tG for ; Wed, 30 Sep 2009 06:21:02 -0700 (PDT) Received: from triton.edu (mail.triton.edu [64.107.218.40]) by core3.amsl.com (Postfix) with ESMTP id 0F3093A695A for ; Wed, 30 Sep 2009 06:20:57 -0700 (PDT) Received: from [212.116.219.172] (account lroberts@triton.edu) by triton.edu (CommuniGate Pro WEBUSER 5.2.14) with HTTP id 6566389; Wed, 30 Sep 2009 08:26:21 -0500 From: "Leslie Roberts" Subject: Winner Winner X-Mailer: CommuniGate Pro WebUser v5.2.14 Date: Wed, 30 Sep 2009 08:26:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1;format="flowed" Content-Transfer-Encoding: 8bit To: undisclosed-recipients:; From the online email ballot promotions held by Motorola Company,your email have been approved to claim the sum of £400,000 (Four hundred thousand pounds) . To file for claim, you are required to provide us with the information below for verification: Full Name: Mailing address: Permanent house address: Country of resident: Phone Number: Sex: Occupation: Reply this email with the information for claim(motorolaprom128@yahoo.com.hk)