From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 07:34:36 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 9A0A23A6A4E for ; Wed, 8 Apr 2009 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 40KS8qYrjaRH for ; Wed, 8 Apr 2009 07:34:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 614AC3A6B36 for ; Wed, 8 Apr 2009 07:32:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C5EE463B1A9; Wed, 8 Apr 2009 14:33:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (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 A1DCC63B18C for ; Wed, 8 Apr 2009 14:33:21 +0000 (UTC) Received: from h222130.nist.gov (h222130.nist.gov [129.6.222.130]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n38D2FPW002545; Wed, 8 Apr 2009 09:02:15 -0400 Message-Id: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> From: Tim Polk To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: applying AES-GCM to secure shell: proposed "tweak" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 09:02:00 -0400 Cc: Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" X-Mailer: Apple Mail (2.930.3) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Folks, The IESG is currently considering publication of draft-igoe-secsh-aes- gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", as an Informational RFC. The draft specifies the application of the Authenticated Encryption with Associated Data (AEAD) block cipher mode AES Galois/Counter Mode to provide both confidentiality and data integrity for SSH. (See RFC 5116, "An Interface and Algorithms for Authenticated Encryption", for a general look at AEAD algorithms and NIST Special Publication 800-38D for the specification of the GCM mode; see URLs below.) The draft was designed to minimize the changes to RFC 4253 (the SSH Transport Layer Protocol), so it encrypts the whole SSH binary packet, including the packet_length field. However, AEAD decryption as defined in both RFC 5116 and SP 800-38D takes the ciphertext as input, and returns either (1) the plaintext if the authentication succeeds or (2) failure. The ciphertext here is an octet string of known length, not an ubounded stream. Since the packet_length field is also encrypted, SSH cannot determine the ciphertext boundary before passing the data to AEAD decryption. (This differs from current SSH encryption modes where the data is first decrypted, then the packet length field is parsed, and finally the MAC is verified.) Two solutions have been proposed: (1) explicitly allowing "partial decryption" so that an implementation can recover the packet_length without authenticating the data; or (2) sending the packet_length unencrypted so that it is always available. The first solution requires less security analysis about SSH, but more analysis about the AEAD algorithm. The exposure of intermediate values in AES GCM would require review, and it is inconsistent with RFC 5116. Even if this solution is determined to be secure for AES GCM, this might not apply to other AEAD algorithms (where returning plaintext fragments before authentication may not be even possible, or may not be secure). In a more parochial concern, inconsistency with SP 800-38D means that current validation processes (i.e. NIST's FIPS 140-based Cryptographic Module Validation Program [CMVP]) would need to be revised, as well as SP 800-38D, to permit use of this protocol with validated modules. The second solution (sending packet_length unencrypted) has a number of desirable properties: it conforms to RFC 5116 so the design should apply to any AEAD algorithm, and it is consistent with the algorithm specification (NIST SP 800-38D). It does require a change to the padding calculations: since the plaintext for encryption excludes the packet_length, the concatenation of the 'padding length', 'payload', and 'random padding' MUST be a multiple of the cipher block size. (This modifies a requirement from Section 6 of RFC 4253.) Since this calculation is algorithm specific anyway, it is hoped this would not be an issue. As you might have guessed, I strongly prefer this solution. However, we are concerned about making such a change without ensuring that the security implications have been thoroughly reviewed. The SSHv1 protocol revealed the exact plaintext length, which is clearly undesirable in many situations (see e.g. link below). In SSHv2, the packet length includes the random padding, so sending it unencrypted does not reveal the exact the plaintext length. Also, in many cases the packet length can be inferred from the data stream (e.g. TCP segment lengths). In applications where there is some fear that the packet lengths might reveal sensitive information, the use of random padding probably provides a much more effective countermeasure than encrypting the packet_length. So, it seems that encryption of the packet_length field would be of little practical use, and might lead to a false sense of security. As a consequence, we hypothesize that sending packet_length in the clear would not negatively impact the security of the protocol. Before moving forward with this protocol using either of the proposed solutions, we would appreciate feedback from this mailing list. Questions to consider: (1) does the exposure of the ssh packet length have significant security implications for ssh itself? (2) were applications that rely on ssh for security designed to take advantage of the encrypted packet length? (3) does the change in padding length calculation (caused by excluding the packet_length from the ciphertext) impose a significant impediment to migrating existing implementations? Thanks, Tim Polk (Security co-AD and document sponsor) P.S. I've tried to contact as many of the usual suspects as possible, but I am sure I have missed some folks. Please forward this to anyone I've left off distribution that might have an interest!] References: http://tools.ietf.org/html/rfc5116 http://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis/ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 09:24:32 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 33A7B3A6B58 for ; Wed, 8 Apr 2009 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, 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 0ykLsw4yK9iE for ; Wed, 8 Apr 2009 09:24:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 620723A6B20 for ; Wed, 8 Apr 2009 09:24:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D294863B124; Wed, 8 Apr 2009 16:25:30 +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 8B3C663B10C for ; Wed, 8 Apr 2009 16:25:26 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7DF429DDE8; Thu, 9 Apr 2009 03:20:36 +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 t9VmqTvSJAd3; Thu, 9 Apr 2009 03:20:36 +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 36DE79DDD3; Thu, 9 Apr 2009 03:20:34 +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 CBB4F1DE4001; Thu, 9 Apr 2009 03:20:33 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrZZp-0003Oq-ND; Thu, 09 Apr 2009 03:20:33 +1200 From: Peter Gutmann To: ietf-ssh@netbsd.org, tim.polk@nist.gov Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Message-Id: Date: Thu, 09 Apr 2009 03:20:33 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list [Followups trimmed somewhat] Tim Polk writes: >(1) does the exposure of the ssh packet length have significant security >implications for ssh itself? Given the recent weakness discovered in OpenSSH (allowing recovery of limited amounts of plaintext due to the length being encrypted), the only effect I can think of is that'd it'd make it more secure, not less. >(2) were applications that rely on ssh for security designed to take >advantage of the encrypted packet length? Not in my case. In fact it's actually a considerable pain since it messes up the stream processing, you can't read and decrypt the entire packet in one clean operation like SSL but have to read and decrypt a bit of it, extract metadata from the start, buffer the rest that was decrypted, read and decrypt the remainder, and then reattach the prevously-decrypted data to the start. >(3) does the change in padding length calculation (caused by excluding the >packet_length from the ciphertext) impose a significant impediment to >migrating existing implementations? Nope. In fact it significantly simplifies them, for the reason given above. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 10:38:28 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 6E5AE3A6B19 for ; Wed, 8 Apr 2009 10:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.235, 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 r1tmCfJ2Sx08 for ; Wed, 8 Apr 2009 10:38:27 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D3DFD3A6A43 for ; Wed, 8 Apr 2009 10:38:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A699D63B10C; Wed, 8 Apr 2009 17:39:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 1D57063B11F for ; Wed, 8 Apr 2009 17:39:21 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38GSAfC003086 for ; Wed, 8 Apr 2009 16:28:10 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 n38GS9De003715 for ; Wed, 8 Apr 2009 10:28: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 n38G3hU0006531; Wed, 8 Apr 2009 11:03:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n38G3cLe006530; Wed, 8 Apr 2009 11:03:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 11:03:38 -0500 From: Nicolas Williams To: Tim Polk Cc: ietf-ssh@NetBSD.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090408160338.GK1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 08, 2009 at 09:02:00AM -0400, Tim Polk wrote: > The draft was designed to minimize the changes to RFC 4253 (the SSH > Transport Layer Protocol), so it encrypts the whole SSH binary packet, > including the packet_length field. As you know encrypting the SSH packet length has caused us nothing but trouble. I recommend sending it in the clear. > Since the packet_length field is also encrypted, SSH cannot determine > the ciphertext boundary before passing the data to AEAD decryption. > (This differs from current SSH encryption modes where the data is > first decrypted, then the packet length field is parsed, and finally > the MAC is verified.) > > Two solutions have been proposed: (1) explicitly allowing "partial > decryption" so that an implementation can recover the packet_length > without authenticating the data; or (2) sending the packet_length > unencrypted so that it is always available. (1) may be impossible to implement with some existing AEAD crypto APIs. Adding AEAD crypto APIs that allow for "partial decryption" is possible, but would add a significant wrinkle in getting this deployed. I strongly recommend (2). It's what all other protocols do. There's also (3): specify two variants of this ssh cipher, one that does not encrypt the packet length (this one would be REQUIRED) and one that does (OPTIONAL). We should do (3) IFF there are implementors who really need to defeat traffic analysis and are up to the task of ensuring that, for example, TCP window changes don't give away SSH message boundaries, and that they use random padding and ignore messages in a way that does hide actual ssh traffic patterns. > The first solution requires less security analysis about SSH, but more > analysis about the AEAD algorithm. The exposure of intermediate values > in AES GCM would require review, and it is inconsistent with RFC > 5116. Even if this solution is determined to be secure for AES GCM, > this might not apply to other AEAD algorithms (where returning > plaintext fragments before authentication may not be even possible, or > may not be secure). In a more parochial concern, inconsistency with SP > 800-38D means that current validation processes (i.e. NIST's FIPS > 140-based Cryptographic Module Validation Program [CMVP]) would need > to be revised, as well as SP 800-38D, to permit use of this protocol > with validated modules. Indeed, (1) is just too painful. > The second solution (sending packet_length unencrypted) has a number > of desirable properties: it conforms to RFC 5116 so the design should > apply to any AEAD algorithm, and it is consistent with the algorithm > specification (NIST SP 800-38D). It does require a change to the > padding calculations: since the plaintext for encryption excludes the > packet_length, the concatenation of the 'padding length', 'payload', > and 'random padding' MUST be a multiple of the cipher block size. > (This modifies a requirement from Section 6 of RFC 4253.) Since this > calculation is algorithm specific anyway, it is hoped this would not > be an issue. As you might have guessed, I strongly prefer this > solution. However, we are concerned about making such a change > without ensuring that the security implications have been thoroughly > reviewed. The fact that SSHv2 encrypts the packet length has been a cause of a significant protocol security vulnerability. Let's kill this encrypt- the-packet-length notion. > So, it seems that encryption of the packet_length field would be of > little practical use, and might lead to a false sense of security. As > a consequence, we hypothesize that sending packet_length in the clear > would not negatively impact the security of the protocol. Agreed. > Before moving forward with this protocol using either of the proposed > solutions, we would appreciate feedback from this mailing list. > Questions to consider: > > (1) does the exposure of the ssh packet length have significant > security implications for ssh itself? Not negative ones. As you say, one may want to ensure the use of random padding to avoid revealing, e.g., password lengths. > (2) were applications that rely on ssh for security designed to take > advantage of the encrypted packet length? Not that I know of. > (3) does the change in padding length calculation (caused by excluding > the packet_length from the ciphertext) impose a significant impediment > to migrating existing implementations? The changes would all be localized to the SSHv2 implementation. There would be more changes to make to an SSHv2 implementation if we go with (2), but (1) requires changes to parts of the system that an SSHv2 implementor may not be in a position to make, thus from a political point of view (2) is clearly easier than (1). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 11:04: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 D6F9028C0E5 for ; Wed, 8 Apr 2009 11:04:01 -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 ST4mYLh6CYjA for ; Wed, 8 Apr 2009 11:04:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 51CD73A6B4F for ; Wed, 8 Apr 2009 11:03:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 02A0F63B104; Wed, 8 Apr 2009 18:04:10 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 6EB7563B12E for ; Wed, 8 Apr 2009 18:04:08 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.63) (envelope-from ) id 1Lras0-0000Su-ID; Wed, 08 Apr 2009 17:43:24 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Subject: Re: applying AES-GCM to secure shell: proposed "tweak" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 08 Apr 2009 17:43:24 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Tim Polk wrote: > Before moving forward with this protocol using either of the proposed > solutions, we would appreciate feedback from this mailing list. > Questions to consider: > > (1) does the exposure of the ssh packet length have significant > security implications for ssh itself? > > (2) were applications that rely on ssh for security designed to take > advantage of the encrypted packet length? > > (3) does the change in padding length calculation (caused by excluding > the packet_length from the ciphertext) impose a significant impediment > to migrating existing implementations? I was thinking about this when the recent vulnerability (CERT VU#958563) was announced. I started thinking about what sort of a binary packet protocol would have been intrinsically immune to problems of that type, and came to similar conclusions: that the problems with SSH-1's cleartext packet lengths arose from having them correspond to the exact semantic size of an SSH message, and it's not the case that cleartext lengths are _inherently_ harmful. I came up with a design for a replacement BPP in two layers: the outer layer divides the wire data stream into blocks each of which is encrypted and MACed as a unit, and then the inner layer conceptually glues the plaintext of all those blocks back together and divides the resulting stream up into SSH messages by means of separate markings within that stream. Then it's safe to send the outer layer's block lengths in cleartext, (a) because they tell a passive listener nothing that they couldn't have deduced from the TCP segment boundaries anyway, and (b) an active attacker cannot replace any block without having to forge a correct MAC for that block. (Naturally the MAC also includes sequence numbers to prevent block-rearrangement attacks.) The division between semantic SSH messages in layer 2 is thus decoupled from the division between blocks in layer 1, meaning that you can transmit several messages in a block (saving space overall!) or split one large message across several blocks if you like. And finally, the MAC is applied to the ciphertext rather than the plaintext, so you end up with a hard guarantee against leakage attacks of the sort described in VU#958563: you cannot trick an implementation into decrypting ciphertext of your choosing and acting as an oracle, because nothing is even _shown_ to the decryption code until it's passed its MAC, so first you would have to forge a correct MAC for your chosen ciphertext. I never quite got round to writing it up and posting it to this list, mostly because I feared the general reaction would be that nobody wanted to go right back to the start of the SSH protocol design process at this stage :-) Would there be interest in seeing it? -- Simon Tatham "A cynic is a person who smells flowers and immediately looks around for a coffin." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 12:04:17 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 2ECF528C165 for ; Wed, 8 Apr 2009 12:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.578, 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 rNSy5Z1Mwv-x for ; Wed, 8 Apr 2009 12:04:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A898E28C29F for ; Wed, 8 Apr 2009 12:03:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9939463B12E; Wed, 8 Apr 2009 19:04:53 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 5932063B14C for ; Wed, 8 Apr 2009 19:04:49 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n38HMZlL028472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 13:22:35 -0400 (EDT) Date: Wed, 08 Apr 2009 13:22:35 -0400 From: Jeffrey Hutzelman To: Tim Polk , ietf-ssh@NetBSD.org cc: Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" , jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 08, 2009 09:02:00 AM -0400 Tim Polk wrote: > The second solution (sending packet_length unencrypted) has a number > of desirable properties: it conforms to RFC 5116 so the design should > apply to any AEAD algorithm, and it is consistent with the algorithm > specification (NIST SP 800-38D). It does require a change to the > padding calculations: since the plaintext for encryption excludes the > packet_length, the concatenation of the 'padding length', 'payload', > and 'random padding' MUST be a multiple of the cipher block size. > (This modifies a requirement from Section 6 of RFC 4253.) Since this > calculation is algorithm specific anyway, it is hoped this would not > be an issue. As you might have guessed, I strongly prefer this > solution. However, we are concerned about making such a change > without ensuring that the security implications have been thoroughly > reviewed. On first glance, this seems reasonable from a security standpoint; as previously noted, we've seen problems resulting from the length being encrypted, and as you've discovered, treating the encryped length as part of the same plaintext it describes leads to some interesting problems trying to read the encrypted packet off of the TCP stream. I am concerned about the implications of an encryption algorithm spec changing parts of the base protocol. The protocol is designed such that there is an abstraction between the transport protocol and the individual compression, encryption, integrity, key exchange, and public key algorithms. You propose introducing an encryption algorithm which requires that the transport protocol itself behave differently when that algorithm is in use, not only in not encrypting the length, but in changing the generation of padding on outgoing messages. I'd rather see an extension to move the length out of the encrypted part of the packet (and makes the required padding changes), which is negotiated separately and can be used with any encryption algorithm. It would then be reasonable to for AEAD encryption algorithms to require support for and use of the new extension. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 13:34: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 87EE23A6B36 for ; Wed, 8 Apr 2009 13:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.459 X-Spam-Level: X-Spam-Status: No, score=-8.459 tagged_above=-999 required=5 tests=[AWL=1.529, 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 IIQ2CcYpYOjO for ; Wed, 8 Apr 2009 13:34:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B4AD53A6A3A for ; Wed, 8 Apr 2009 13:34:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 16AB063B178; Wed, 8 Apr 2009 20:35: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 3D94163B112 for ; Wed, 8 Apr 2009 20:35:27 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA22321; Wed, 8 Apr 2009 16:35:25 -0400 (EDT) From: der Mouse Message-Id: <200904082035.QAA22321@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, 8 Apr 2009 16:30:21 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > I am concerned about the implications of an encryption algorithm spec > changing parts of the base protocol. I'm not sure that's really what's going on here. I really need to find the time to go read the spec, but from what I've gathered from the list, this could, as far as the core protocol is concerned, be seen as an encryption algorithm that happens to produce ciphertext identical to the plaintext for certain parts of the data stream. Does that weaken the security assurances provided by the protocol? I don't know. My feeling is that it doesn't, but there's lots of counterintuitive stuff running around crypto, and I'd need to think about it a lot more to have any degree of confidence that's right. /~\ 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 Apr 8 14: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 03FEC3A6E97 for ; Wed, 8 Apr 2009 14:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 iVbP3D7i+qC3 for ; Wed, 8 Apr 2009 14:53:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 20DDD3A6E87 for ; Wed, 8 Apr 2009 14:53:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B35C863B145; Wed, 8 Apr 2009 21:54:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 13A1E63B151 for ; Wed, 8 Apr 2009 21:54:24 +0000 (UTC) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n38L5Gmh016614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 17:05:17 -0400 (EDT) Date: Wed, 08 Apr 2009 17:05:16 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 08, 2009 04:30:21 PM -0400 der Mouse wrote: >> I am concerned about the implications of an encryption algorithm spec >> changing parts of the base protocol. > > I'm not sure that's really what's going on here. I really need to find > the time to go read the spec, but from what I've gathered from the > list, this could, as far as the core protocol is concerned, be seen as > an encryption algorithm that happens to produce ciphertext identical to > the plaintext for certain parts of the data stream. I wouldn't have a problem with that, but it's not actually the case. The base protocol spec assumes that encryption algorithms have a block size, and requires that the amount of padding be chosen such that the combined size of the length, padding length, padding, and payload be a multiple of the block size. Moving the length out of the encrypted part requires changing this behavior. Separately, I'd like to see an unencrypted-length option so we can negotiate its use even when not using an AEAD encryption algorithm. > Does that weaken the security assurances provided by the protocol? I > don't know. My feeling is that it doesn't, but there's lots of > counterintuitive stuff running around crypto, and I'd need to think > about it a lot more to have any degree of confidence that's right. Agreed. We know about problems with encrypting the length as we do now, but I think we need to consider the implications of leaving it unencrypted fairly carefully. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 17:07: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 906F63A6A41 for ; Wed, 8 Apr 2009 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.479 X-Spam-Level: X-Spam-Status: No, score=-7.479 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, MANGLED_FROM=2.3, 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 u6EAmdYmM4kj for ; Wed, 8 Apr 2009 17:07:50 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A8DDE3A6988 for ; Wed, 8 Apr 2009 17:07:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 858B263B11C; Thu, 9 Apr 2009 00:08:51 +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 D457363B14D for ; Thu, 9 Apr 2009 00:08:47 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA23669; Wed, 8 Apr 2009 20:08:47 -0400 (EDT) From: der Mouse Message-Id: <200904090008.UAA23669@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, 8 Apr 2009 19:28:45 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> [F]rom what I've gathered from the list, this could, as far as the >> core protocol is concerned, be seen as an encryption algorithm that >> happens to produce ciphertext identical to the plaintext for certain >> parts of the data stream. > I wouldn't have a problem with that, but it's not actually the case. > The base protocol spec assumes that encryption algorithms have a > block size, and requires that the amount of padding be chosen such > that the combined size of the length, padding length, padding, and > payload be a multiple of the block size. Right - with an artificial block size imposed for stream ciphers. (Actually, the wording in RFC4253 is not very good; consider what an implementer reading the "Note that the..." paragraph beginning ten or so lines into page 8 would do with a cipher using 7-byte blocks.) > Moving the length out of the encrypted part requires changing this > behavior. Why? As far as I can see, this is so only if (a) the underlying cipher has a block size that's not a divisor of 4 bytes and (b) you insist on naïvely treating all the sent-encrypted data as a single data stream for the encryption engine. It would be very easy, for example, to use arcfour (or any other stream cipher) to encrypt all but the length. Also, I just reread section 6 of 4253, and I can't find anything that says the ciphertext from an encryption algorithm has to be the same size as the plaintext, so you could always just save the length, replace it with four random bytes, encrypt as normal, and prepend the saved length. (Decryption, of course, just throws away the four random bytes.) /~\ 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 Apr 8 17:15:05 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 C2B3C3A6A91 for ; Wed, 8 Apr 2009 17:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=0.232, 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 vGv3Hjclm1ej for ; Wed, 8 Apr 2009 17:15:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C0D843A68F5 for ; Wed, 8 Apr 2009 17:15:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D6B6163B158; Thu, 9 Apr 2009 00:16:05 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id 4EF9F63B120 for ; Thu, 9 Apr 2009 00:16:03 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n38NBCCc019573 for ; Wed, 8 Apr 2009 23:11:12 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 n38NBBR9052756 for ; Wed, 8 Apr 2009 17:11:11 -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 n38MdJhq006834; Wed, 8 Apr 2009 17:39:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n38MdFKG006833; Wed, 8 Apr 2009 17:39:15 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 17:39:15 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Tim Polk , ietf-ssh@NetBSD.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090408223914.GU1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 08, 2009 at 01:22:35PM -0400, Jeffrey Hutzelman wrote: > I am concerned about the implications of an encryption algorithm spec > changing parts of the base protocol. The protocol is designed such that > there is an abstraction between the transport protocol and the individual > compression, encryption, integrity, key exchange, and public key > algorithms. You propose introducing an encryption algorithm which requires > that the transport protocol itself behave differently when that algorithm > is in use, not only in not encrypting the length, but in changing the > generation of padding on outgoing messages. What would the negotiation look like? Would it apply to existing ciphers as well? [So far the only extensibility mechanisms that we have at that point in the protocol are: new protocol version number (not going to happen) and magic algorithm names (which have been used successfully).] Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 20:26: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 EBF1D3A68B1 for ; Wed, 8 Apr 2009 20:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, 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 LivhJ+Rxucw6 for ; Wed, 8 Apr 2009 20:26:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0EB433A696F for ; Wed, 8 Apr 2009 20:26:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E300163B117; Thu, 9 Apr 2009 03:27:48 +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 AD97263B10E for ; Thu, 9 Apr 2009 03:27:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 82CD09D952; Thu, 9 Apr 2009 15:27:40 +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 AASTdX-sL8YC; Thu, 9 Apr 2009 15:27:40 +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 A7E4A9D944; Thu, 9 Apr 2009 15:27:35 +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 DD1141DE4002; Thu, 9 Apr 2009 15:27:30 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrkvK-0006Tw-NS; Thu, 09 Apr 2009 15:27:30 +1200 From: Peter Gutmann To: Nicolas.Williams@sun.com, tim.polk@nist.gov Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, ylo@ssh.com In-Reply-To: <20090408160338.GK1500@Sun.COM> Message-Id: Date: Thu, 09 Apr 2009 15:27:30 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: >The fact that SSHv2 encrypts the packet length has been a cause of a >significant protocol security vulnerability. Let's kill this encrypt- the- >packet-length notion. If we're going to make this change, could we also consider moving *all* ciphers to nonencrypted lengths? This currently requires horribly complex code to process, and it's the very first thing an attacker will hit (that is, the first bit of client/server code an incoming, possibly hostile packet, will encounter is the complex encrypted-length processing). It'd be really nice to be able to switch this off to reduce the attack surface, subject to negotiation that the other side supports it, obviously. There's a 32-bit flags field in the handshake that's currently unused, one bit could be used to indicate unencrypted lengths. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 21:32: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 B5EC03A6BE3 for ; Wed, 8 Apr 2009 21:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[AWL=0.231, 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 v1QfU0EtiT1O for ; Wed, 8 Apr 2009 21:32:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B64EF28C10A for ; Wed, 8 Apr 2009 21:31:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2C04963B126; Thu, 9 Apr 2009 04:32:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id E7B2963B17D for ; Thu, 9 Apr 2009 04:32:47 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n394Wlk4028925 for ; Thu, 9 Apr 2009 04:32:47 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 n394Wl8A035795 for ; Wed, 8 Apr 2009 22:32:47 -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 n3940t83006930; Wed, 8 Apr 2009 23:00:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3940tVR006929; Wed, 8 Apr 2009 23:00:55 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 23:00:55 -0500 From: Nicolas Williams To: Peter Gutmann Cc: tim.polk@nist.gov, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090409040055.GY1500@Sun.COM> References: <20090408160338.GK1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 03:27:30PM +1200, Peter Gutmann wrote: > Nicolas Williams writes: > > >The fact that SSHv2 encrypts the packet length has been a cause of a > >significant protocol security vulnerability. Let's kill this encrypt- the- > >packet-length notion. > > If we're going to make this change, could we also consider moving *all* > ciphers to nonencrypted lengths? This currently requires horribly complex Not with a flag day. Implementors will have to keep implementing the old thing for a long time. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 21:34:28 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 998C23A6B07 for ; Wed, 8 Apr 2009 21:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.421 X-Spam-Level: X-Spam-Status: No, score=-4.421 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, 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 RYgjkPuHzbwg for ; Wed, 8 Apr 2009 21:34:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 90C173A69B6 for ; Wed, 8 Apr 2009 21:34:27 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3C0D963B11E; Thu, 9 Apr 2009 04:35:30 +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 EDE9B63B101 for ; Thu, 9 Apr 2009 04:35:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F0E5D9E132; Thu, 9 Apr 2009 15:51:36 +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 IB-cQu3l0e52; Thu, 9 Apr 2009 15:51:36 +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 66AAE9E0FA; Thu, 9 Apr 2009 15:51: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 B97491DE4001; Thu, 9 Apr 2009 15:51:35 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrlId-0007gs-IZ; Thu, 09 Apr 2009 15:51:35 +1200 From: Peter Gutmann To: jhutz@cmu.edu, Nicolas.Williams@sun.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com In-Reply-To: <20090408223914.GU1500@Sun.COM> Message-Id: Date: Thu, 09 Apr 2009 15:51:35 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: >[So far the only extensibility mechanisms that we have at that point in the >protocol are: new protocol version number (not going to happen) and magic >algorithm names (which have been used successfully).] ... and the completely unused 32-bit flags field in the first message, which I mentioned previously :-). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 21:36:20 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 343323A6A67 for ; Wed, 8 Apr 2009 21:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.230, 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 giVwtrSoeDVR for ; Wed, 8 Apr 2009 21:36:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 360BB3A680E for ; Wed, 8 Apr 2009 21:36:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B8AB63B13E; Thu, 9 Apr 2009 04:37:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id A988763B128 for ; Thu, 9 Apr 2009 04:37:21 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n394bKIA001732 for ; Thu, 9 Apr 2009 04:37:20 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 n394bKx5037583 for ; Wed, 8 Apr 2009 22:37:20 -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 n393vsAP006916; Wed, 8 Apr 2009 22:57:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n393vnfZ006915; Wed, 8 Apr 2009 22:57:49 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 22:57:49 -0500 From: Nicolas Williams To: Peter Gutmann Cc: jhutz@cmu.edu, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090409035749.GX1500@Sun.COM> References: <20090408223914.GU1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 03:51:35PM +1200, Peter Gutmann wrote: > Nicolas Williams writes: > > >[So far the only extensibility mechanisms that we have at that point in the > >protocol are: new protocol version number (not going to happen) and magic > >algorithm names (which have been used successfully).] > > ... and the completely unused 32-bit flags field in the first message, which I > mentioned previously :-). This: uint32 0 (reserved for future extension) ? Yes, that could be used too. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 21:38:22 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 99FA83A68D0 for ; Wed, 8 Apr 2009 21:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.230, 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 69TJ+mrdj5Af for ; Wed, 8 Apr 2009 21:38:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 96BF23A680E for ; Wed, 8 Apr 2009 21:38:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 77D5D63B159; Thu, 9 Apr 2009 04:39:24 +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 EA10163B128 for ; Thu, 9 Apr 2009 04:39:22 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n394dMAa004019 for ; Thu, 9 Apr 2009 04:39:22 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 n394dMFg038192 for ; Wed, 8 Apr 2009 22:39:22 -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 n39401tk006924; Wed, 8 Apr 2009 23:00:01 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39401hi006923; Wed, 8 Apr 2009 23:00:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 8 Apr 2009 23:00:01 -0500 From: Nicolas Williams To: Peter Gutmann Cc: jhutz@cmu.edu, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090409040001.GM1667@Sun.COM> References: <20090408223914.GU1500@Sun.COM> <20090409035749.GX1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090409035749.GX1500@Sun.COM> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 08, 2009 at 10:57:49PM -0500, Nicolas Williams wrote: > On Thu, Apr 09, 2009 at 03:51:35PM +1200, Peter Gutmann wrote: > > Nicolas Williams writes: > > > > >[So far the only extensibility mechanisms that we have at that point in the > > >protocol are: new protocol version number (not going to happen) and magic > > >algorithm names (which have been used successfully).] > > > > ... and the completely unused 32-bit flags field in the first message, which I > > mentioned previously :-). > > This: > > uint32 0 (reserved for future extension) > > ? > > Yes, that could be used too. Er, actually, I'm not sure. It depends on what implementations do with it now when it's not set to 0. Hmmm, what does the spec say to do about that field? Sadly: nothing, at least not in section 7.1. That probably means that we can't use that field. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 21:40:20 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 163743A6A7D for ; Wed, 8 Apr 2009 21:40:20 -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 RfYWs9+VOm3M for ; Wed, 8 Apr 2009 21:40:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C2AE03A68A5 for ; Wed, 8 Apr 2009 21:40:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 72FEA63B15A; Thu, 9 Apr 2009 04:41:23 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 60AED63B14D for ; Thu, 9 Apr 2009 04:41:21 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id D81AAC4AFE; Thu, 9 Apr 2009 13:25:57 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 79373C4ACD; Thu, 9 Apr 2009 13:25:51 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id E9B49A4F6D; Thu, 9 Apr 2009 13:25:50 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id E7513A4F6C; Thu, 9 Apr 2009 13:25:50 +1000 (EST) Date: Thu, 9 Apr 2009 13:25:50 +1000 (EST) From: Damien Miller To: Tim Polk cc: ietf-ssh@netbsd.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 8 Apr 2009, Tim Polk wrote: > Folks, > > The IESG is currently considering publication of draft-igoe-secsh-aes- > gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer > Protocol", as an Informational RFC. The draft specifies the > application of the Authenticated Encryption with Associated Data > (AEAD) block cipher mode AES Galois/Counter Mode to provide both > confidentiality and data integrity for SSH. (See RFC 5116, "An > Interface and Algorithms for Authenticated Encryption", for a general > look at AEAD algorithms and NIST Special Publication 800-38D for the > specification of the GCM mode; see URLs below.) > > The draft was designed to minimize the changes to RFC 4253 (the SSH > Transport Layer Protocol), so it encrypts the whole SSH binary packet, > including the packet_length field. > > However, AEAD decryption as defined in both RFC 5116 and SP 800-38D > takes the ciphertext as input, and returns either (1) the plaintext if > the authentication succeeds or (2) failure. The ciphertext here is an > octet string of known length, not an ubounded stream. > > Since the packet_length field is also encrypted, SSH cannot determine > the ciphertext boundary before passing the data to AEAD decryption. > (This differs from current SSH encryption modes where the data is > first decrypted, then the packet length field is parsed, and finally > the MAC is verified.) > > Two solutions have been proposed: (1) explicitly allowing "partial > decryption" so that an implementation can recover the packet_length > without authenticating the data; or (2) sending the packet_length > unencrypted so that it is always available. another option, would be encrypting the length field with an independently-keyed cipher, but I doubt that it is worth it. I'd agree that simply leaving the length fields unencrypted would be best, but the security considerations should mention the need to use padding to avoid revealing secrets, especially for password userauth. Some general comments on the draft: First, why GCM? Some rationale would be nice. 4.1 Key exchange implies modification to the matching rules, but doesn't IMO sufficiently spell out exactly how matching should occur when the GCM method appears in various positions of the client and server's lists. 5.1/5.2 - The suggested algorithm names are structurally different to the other algorithm identifiers used in SSH. In particular, I don't see any need for the "-ssh" to appear in the algorithm name as the cipher has not been modified in any substantial way. Why not just "aes128-gcm" or "aes128-gcm-aead" if you wanted to be particularly verbose? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 22:09:22 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 C6A793A68A5 for ; Wed, 8 Apr 2009 22:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.733, 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 FQ+aYCUZZFev for ; Wed, 8 Apr 2009 22:09:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D7B533A6BA1 for ; Wed, 8 Apr 2009 22:09:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B674463B113; Thu, 9 Apr 2009 05:10:21 +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 70FD163B14D for ; Thu, 9 Apr 2009 05:10:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 532C3482BC4; Thu, 9 Apr 2009 17:10:19 +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 q7Q0XHirhx6T; Thu, 9 Apr 2009 17:10:19 +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 3F08F482BE3; Thu, 9 Apr 2009 17:10:15 +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 A9CDD1A04001; Thu, 9 Apr 2009 17:10:13 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrmWj-0001u4-EQ; Thu, 09 Apr 2009 17:10:13 +1200 From: Peter Gutmann To: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, jhutz@cmu.edu, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com In-Reply-To: <20090409040001.GM1667@Sun.COM> Message-Id: Date: Thu, 09 Apr 2009 17:10:13 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: >Er, actually, I'm not sure. It depends on what implementations do with it >now when it's not set to 0. Hmmm, what does the spec say to do about that >field? Sadly: nothing, at least not in section 7.1. Well if it's RFU then it's implied that you ignore it, which has been the practice for RFU fields since at least the 1970s (in things like status flags registers), and probably even earlier but I wasn't playing with computer hardware back then. How about a quick straw poll, since we've probably got a good number of implemeters here. If your implementation sees a non-zero value in the RFU field, will it: 1. Ignore it and continue, since it's RFU. 2. Run Nethack, and failing that, emacs in Towers-of-Hanoi mode. 3. Reformat the hard drive. 4. ??? 5. Profit. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 22:30: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 178E03A6BA1 for ; Wed, 8 Apr 2009 22:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.65 X-Spam-Level: X-Spam-Status: No, score=-8.65 tagged_above=-999 required=5 tests=[AWL=1.338, 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 qd61UJK-dmMo for ; Wed, 8 Apr 2009 22:30:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C7B5C3A6BD7 for ; Wed, 8 Apr 2009 22:30:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0AA4A63B14D; Thu, 9 Apr 2009 05:31: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 49B9163B146 for ; Thu, 9 Apr 2009 05:31:09 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id BAA25375; Thu, 9 Apr 2009 01:31:08 -0400 (EDT) From: der Mouse Message-Id: <200904090531.BAA25375@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, 8 Apr 2009 23:44:09 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > If we're going to make this change, could we also consider moving > *all* ciphers to nonencrypted lengths? This currently requires > horribly complex code to process, That wasn't my experience as an implementor. Perhaps you're trying to (ab)use cryptosystem interfaces not designed for that style of use? > There's a 32-bit flags field in the handshake that's currently > unused, one bit could be used to indicate unencrypted lengths. I suspect that will not interoperate well with implementations not supporting plaintext lengths. I see no guidance in 4253 as to what protocol speakers should do if that flags field is nonzero (or, more generally, has non-understood bits set) in an incoming packet, and suspect I'm not the only implementor who's simply ignored it (which won't interoperate) or checked it and errored if it's nonzero (which won't interoperate either). That flags field was ill-thought-out, and I wish I'd noticed it before the drafts were turned into RFCs. I would suggest creating new packet type for negotiating options like this. As a strawman: byte SSH_MSG_OPTION (value = 7) string option name ... option-specific data The option name uses the DNS-based extensibility mechanism (4251 section 6); all data after the option name, including types and values, is option-specific and is described in the definition of the option. SSH_MSG_OPTION may be sent at any time, except that specific option definitions may impose additional restrictions for packets naming that option. Implementations that do not understand SSH_MSG_OPTION MUST respond to it with SSH_MSG_UNIMPLEMENTED, as specifeid in 4253 11.4. The option name "unimplemented" is reserved; it is used to indicate that SSH_MSG_OPTION is implemented but that a particular option is not implemented (or is disabled for the connection in question by a configuration mechanism). Its additional data consists of a single string, which contains the unimplemented option name from the request that provoked the packet. SSH_MSG_OPTION packets with "unimplemented" as the option name MUST NOT be sent under any other circumstances. Option definitions MUST indicate what semantics SSH_MSG_UNIMPLEMENTED and "unimplemented" responses have for the options they define. As a further strawman: I propose the option name "cleartext-packet-lengths". Option-specific data is a single string, which MUST be "on", "off", "ack", "nak", or "mark". Packets for this option with other than exactly one string of additional data, or with other than one of those five strings as the additional data string, are reserved for future standardization; an implementation of this spec MUST respond with a "nak" message to any such packet it recieves. Cleartext packet length use is negotiated separately in each direction. There are two states (in each direction): the negotiated state and the live state. The negotiated state is used to negotiate the option; the live state controls whether packet generation is affected. Both states are "off" at connection startup. Negotiation for each direction is initiated by the peer sending packets in that direction; the sender sends an "on" or "off" packet, indicating whether it proposes to turn the option on or off, to which the receiver MUST respond with an "ack" or "nak" packet, indicating acceptance or rejection of the request. A sender MUST change its record of the negotiated state to match the corresponding "on" or "off" packet, upon receiving an "ack" response; it MUST NOT make any such change upon receiving a "nak" response. A sender may also send a "mark" packet; when it does so, it MUST, between sending that packet and the packet immediately following, copy the negotiated state to the live state. A sender MUST NOT change its live state under any other circumstances. (To avoid indeterminate behaviour, a sender MUST NOT send a "mark" when an "on" or "off" packet has been sent but no corresponding "ack" or "nak" has been received, unless the resulting negotiated state would be the same regardless of which response is received.) A sender MAY choose to delay, or not send at all, a "mark" after a negotiation, even one that changes the negotiated state. There also is no requirement that any change to the negotiated state, nor indeed any negotiation at all, take place before sending a "mark" (though the "mark" will, of course, not correspond to a change in the live state in such a case). An SSH_MSG_UNIMPLEMENTED packet or an "unimplemented" SSH_MSG_OPTION packet (collectively, an "error packet") must always be handled so as to disable the option - that is, when it is in response to an "on", it is to be treated as a "nak"; in response to "off", as an "ack". Implementations MUST NOT generate error packets in response to packets for this option after responding in any other way to any packet for this option on the same connection (but MAY switch in the other direction, responding with a non-error packet after responding with an error packet). This means that an error packet in response to a "mark" can be ignored, since the "mark" must not mark any actual change in the live state, and that an error packet in response to an "ack" or "nak" indicates a broken implementation. When the live state is "off", the connection operates as it would if this option were not implemented. When the live state is "on", the binary packet protocol described in 4253 section 6 is modified. The definition of the value in the packet_length field is unchanged, but that field is not part of the encryption data stream; it is effectively removed from the packet for purposes of computing padding amounts and encryption. It is sent in the data stream, unencrypted, before (the encryption of) the rest of the packet. /~\ 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 Apr 8 22:31: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 BC4503A6B18 for ; Wed, 8 Apr 2009 22:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.687, 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 Q1Tv3w6EXxK2 for ; Wed, 8 Apr 2009 22:31:10 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0D7D73A68A5 for ; Wed, 8 Apr 2009 22:31:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 975AF63B142; Thu, 9 Apr 2009 05:32:14 +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 605C663B101 for ; Thu, 9 Apr 2009 05:32:11 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2D2F71A3B7; Thu, 9 Apr 2009 16:26: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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BbJp2Ui+aK4; Thu, 9 Apr 2009 16:26: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 80E7B1A3B1; Thu, 9 Apr 2009 16:26:25 +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 EF2F41DE4001; Thu, 9 Apr 2009 16:26:24 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrlqK-0001Hr-Ph; Thu, 09 Apr 2009 16:26:24 +1200 From: Peter Gutmann To: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com In-Reply-To: <20090409040055.GY1500@Sun.COM> Message-Id: Date: Thu, 09 Apr 2009 16:26:24 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: >Not with a flag day. Implementors will have to keep implementing the old >thing for a long time. I meant with a bit-flag day, not a flag day. In other words if the uint32 at the end of the SSH_MSG_KEXINIT contains a 1-bit (say in the LSB) for both sides' KEXINIT then things proceed with unencrypted lengths. (This isn't entirely satisfactory because encryption is turned on before MITM detection occurs so you're vulnerable for at least one message, but at least it massively constrains the attack surface from "any message" to "one fixed message during the handshake"). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 23:02:38 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 33A133A68F8 for ; Wed, 8 Apr 2009 23:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.647, 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 lfqvKmZyFuFy for ; Wed, 8 Apr 2009 23:02:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 437853A6878 for ; Wed, 8 Apr 2009 23:02:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 70FC363B120; Thu, 9 Apr 2009 06:03:37 +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 DE1F463B164 for ; Thu, 9 Apr 2009 06:03:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 597C91B340; Thu, 9 Apr 2009 18:03:33 +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 0tJ+cAgoe9sr; Thu, 9 Apr 2009 18:03:33 +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 057201B33D; Thu, 9 Apr 2009 18:03:31 +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 E54BC1DE4002; Thu, 9 Apr 2009 18:03:29 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LrnMH-00057q-Ld; Thu, 09 Apr 2009 18:03:29 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904090531.BAA25375@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Thu, 09 Apr 2009 18:03:29 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: >> If we're going to make this change, could we also consider moving >> *all* ciphers to nonencrypted lengths? This currently requires >> horribly complex code to process, > >That wasn't my experience as an implementor. Perhaps you're trying to (ab) >use cryptosystem interfaces not designed for that style of use? No, just doing it properly. >I would suggest creating new packet type for negotiating options like this. >As a strawman: > > byte SSH_MSG_OPTION (value = 7) > string option name > ... option-specific data Actually that would have been my preference as well, at the moment SSH has no facility for interoperable extensibility beyond defining entire new message types via (presumably) standards-track RFCs. Having an extension mechanism like TLS would greatly assist in introducing new features, or enhancing existing ones. >SSH_MSG_OPTION may be sent at any time, except that specific option >definitions may impose additional restrictions for packets naming that >option. Ugh, I would restrict this to specific places, e.g. right after the KEXINIT and and couple of other well-defined redezvous points, not at any time. If you allow either side to set protocol behaviour-changing options at any point you're going to end up with a huge interop headache. >I propose the option name "cleartext-packet-lengths". > >[Multi-page description of incredibly complex negotiation snipped] Again, this is never going to work if you expect different implementations to interoperate cleanly. What's wrong with "if both sides send 'cleartext- packet-lengths' then you continue with unencrypted lengths, otherwise you don't"? Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 23:32: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 53BE63A68F8 for ; Wed, 8 Apr 2009 23:32:56 -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 U7m1UwV-Wokh for ; Wed, 8 Apr 2009 23:32:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7DB9E3A6B10 for ; Wed, 8 Apr 2009 23:32:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D6F3E63B171; Thu, 9 Apr 2009 06:33:54 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id EC1D263B160 for ; Thu, 9 Apr 2009 06:33:52 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 6539AC4AFE; Thu, 9 Apr 2009 16:33:50 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 9F5CBC4ACD; Thu, 9 Apr 2009 16:33:44 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 1D1A3A4F6D; Thu, 9 Apr 2009 16:33:44 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 1ACB6A4F6C; Thu, 9 Apr 2009 16:33:44 +1000 (EST) Date: Thu, 9 Apr 2009 16:33:44 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: jhutz@cmu.edu, Nicolas.Williams@sun.com, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 9 Apr 2009, Peter Gutmann wrote: > Nicolas Williams writes: > > >[So far the only extensibility mechanisms that we have at that point in the > >protocol are: new protocol version number (not going to happen) and magic > >algorithm names (which have been used successfully).] > > ... and the completely unused 32-bit flags field in the first message, which I > mentioned previously :-). I think it would be much safer to define new cipher names for this. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 8 23: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 1D56C3A6BDB for ; Wed, 8 Apr 2009 23:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.771 X-Spam-Level: X-Spam-Status: No, score=-8.771 tagged_above=-999 required=5 tests=[AWL=1.217, 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 6T-yw0qsGrHC for ; Wed, 8 Apr 2009 23:35:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B46F63A685E for ; Wed, 8 Apr 2009 23:35:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D99A063B163; Thu, 9 Apr 2009 06:36:42 +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 252EE63B168 for ; Thu, 9 Apr 2009 06:36:40 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id CAA25606; Thu, 9 Apr 2009 02:36:40 -0400 (EDT) From: der Mouse Message-Id: <200904090636.CAA25606@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: Thu, 9 Apr 2009 02:16:34 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> SSH_MSG_OPTION may be sent at any time, except that specific option >> definitions may impose additional restrictions for packets naming >> that option. > Ugh, I would restrict this to specific places, e.g. right after the > KEXINIT and and couple of other well-defined redezvous points, not at > any time. If you allow either side to set protocol > behaviour-changing options at any point you're going to end up with a > huge interop headache. That was my first thought, to restrict it to (for this case) use during kex. I was unable to come up with a way to do that that I was sure didn't have nasty races or deadlocks - especially since the number of packets required for kex is variable. Anyway, SSH_MSG_OPTION as I defined it is not restricted to things suitable for use during kex. But if you have an option that you want to negotiate there, you can define it to be an error at any other time. >> I propose the option name "cleartext-packet-lengths". [...] > Again, this is never going to work if you expect different > implementations to interoperate cleanly. What's wrong with "if both > sides send 'cleartext-packet-lengths' then you continue with > unencrypted lengths, otherwise you don't"? First, it rqeuires that it be done in both directions or neither, which is very un-ssh. Everything else about the connection (encryption, MAC, etc) is negotiated separately in each direction. Second, it doesn't define the point at which these messages are sent, nor the point at which unencrypted packet lengths come into use. That can't work. Third, if one side tries to turn it on and the other doesn't, the connection is left in an uncertain half-done state, where the other side may finally mention it and clarify everything, but what happens if that never happens? If you have something better to suggest, go ahead. Just make sure it's precise enough to implement; most of the verbiage that put you off was precision and error handling, not the core of the spec. I was just scribbling something down; it's possible, even likely, it could be done much better. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 00:45: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 2DE5C3A6EA9 for ; Thu, 9 Apr 2009 00:45:30 -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 gI-+DaJH9ylh for ; Thu, 9 Apr 2009 00:45:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5132C3A6E82 for ; Thu, 9 Apr 2009 00:45:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6CA3763B15B; Thu, 9 Apr 2009 07:46:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 43CA863B128 for ; Thu, 9 Apr 2009 07:46:22 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id CF68DC4AFE; Thu, 9 Apr 2009 16:50:56 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 52FC2C4ACD; Thu, 9 Apr 2009 16:50:51 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id D7335A4F6D; Thu, 9 Apr 2009 16:50:50 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id D6AB0A4F6C; Thu, 9 Apr 2009 16:50:50 +1000 (EST) Date: Thu, 9 Apr 2009 16:50:50 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904090531.BAA25375@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <200904090531.BAA25375@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 8 Apr 2009, der Mouse wrote: > I would suggest creating new packet type for negotiating options like > this. As a strawman: > > byte SSH_MSG_OPTION (value = 7) > string option name > ... option-specific data I think any option that changes the binary packet format would need to be included in the kex hash to prevent downgrade/upgrade attacks. This is somewhat annoying implementation-wise if it is a separate packet. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 01:24:20 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 57D1B3A6AFF for ; Thu, 9 Apr 2009 01:24:20 -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 uZLf1EMK9WVh for ; Thu, 9 Apr 2009 01:24:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 75F273A67DB for ; Thu, 9 Apr 2009 01:24:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B2EEB63B160; Thu, 9 Apr 2009 08:25:19 +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 73A3363B128 for ; Thu, 9 Apr 2009 08:25:17 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D106540002; Thu, 9 Apr 2009 09:22:18 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id C5A2E40082; Thu, 9 Apr 2009 09:22:18 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id AA1BB40002; Thu, 9 Apr 2009 09:22:18 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n397MTh8003126; Thu, 9 Apr 2009 09:22:29 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n397MRuj003125; Thu, 9 Apr 2009 09:22:27 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Tim Polk , ietf-ssh@netbsd.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 09 Apr 2009 09:22:27 +0200 In-Reply-To: (Damien Miller's message of "Thu, 9 Apr 2009 13:25:50 +1000 (EST)") 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 Damien Miller writes: > another option, would be encrypting the length field with an > independently-keyed cipher, but I doubt that it is worth it. Actually, I think that's clever! It's natural to use somewhat different mechanisms for data that's fixed size, and data that is of variable size. The length field must still be properly autenticted together with the data, but maybe that is done implicitly with AEAD? /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 02:00: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 3D9BD3A6B7E for ; Thu, 9 Apr 2009 02:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 USb4litgQcpj for ; Thu, 9 Apr 2009 02:00:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 148C53A69B6 for ; Thu, 9 Apr 2009 02:00:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D35CA63B161; Thu, 9 Apr 2009 09:01:32 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 18DCF63B12F for ; Thu, 9 Apr 2009 09:01:30 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n39918VQ014357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 12:01:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n39915k1012350; Thu, 9 Apr 2009 12:01:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18909.47441.579568.878467@fireball.kivinen.iki.fi> Date: Thu, 9 Apr 2009 12:01:05 +0300 From: Tero Kivinen To: Nicolas Williams Cc: Peter Gutmann , jhutz@cmu.edu, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090409040001.GM1667@Sun.COM> References: <20090408223914.GU1500@Sun.COM> <20090409035749.GX1500@Sun.COM> <20090409040001.GM1667@Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 17 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: > On Wed, Apr 08, 2009 at 10:57:49PM -0500, Nicolas Williams wrote: > > On Thu, Apr 09, 2009 at 03:51:35PM +1200, Peter Gutmann wrote: > > > Nicolas Williams writes: > > > > > > >[So far the only extensibility mechanisms that we have at that point in the > > > >protocol are: new protocol version number (not going to happen) and magic > > > >algorithm names (which have been used successfully).] > > > > > > ... and the completely unused 32-bit flags field in the first message, which I > > > mentioned previously :-). > > > > This: > > > > uint32 0 (reserved for future extension) > > > > ? > > > > Yes, that could be used too. > > Er, actually, I'm not sure. It depends on what implementations do with > it now when it's not set to 0. Hmmm, what does the spec say to do about > that field? Sadly: nothing, at least not in section 7.1. > > That probably means that we can't use that field. Not sure about the Secure shell implementations, but on the IKEv1 implementations I have seen that security people have usually not been very liberal what they accept unless that is explicitly spelled out in the RFC, i.e. I would expect there are implementations which will fail negotiation if the reserved field is not zero (yes, those could be considered as broken implementations). Another possibility to negotiate this per cipher is to encode it as part of the cipher name, i.e. define in this AES-GCM document (or make it separate document, so other AEAD ciphers can refer it independently to the AES-GCM) that if the cipher name for example starts with "*" (ASCII-character 052, 42, 0x2a) then cipher uses clear text length field. In that case implementations can either just check the name completely, i.e. know that "*aead-aes-128-gcm" and "*aead-aes-256-gcm" ciphes use this format, or they can simply see that if first character of the cipher is "*" then it uses this new format and check if the rest of the cipher name is valid, and use that as real cipher. That would allow implementations ability to propose cipher lists like "aes256-cbc,*aes256-cbc,*aead-aes-256-gcm" if needed. The question is do people really want to use old ciphers also with clear text length field? If so then this would allow easy configuration to support those for even old implementations with minimal changes, and backward compatibility with old versions (I do not think we can find a secure shell implementation which breaks when it sees unknown cipher name in cipher lists). Anyways if we go to the clear text packet length, the security considerations section of the document describing it needs to give more information, as RFC4251 (SSH-Arch) does not cover that case. -- kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 02:14:21 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 6444B3A6B86 for ; Thu, 9 Apr 2009 02:14:21 -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 27TlQ-rqDA7N for ; Thu, 9 Apr 2009 02:14:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 48D393A6839 for ; Thu, 9 Apr 2009 02:14:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B5EEB63B128; Thu, 9 Apr 2009 09:15:20 +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 9514D63B14B for ; Thu, 9 Apr 2009 09:15:17 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CD94E4007C; Thu, 9 Apr 2009 09:14:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id C12C5400A3; Thu, 9 Apr 2009 09:14:14 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 917CB4007C; Thu, 9 Apr 2009 09:14:14 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n397EPLB002837; Thu, 9 Apr 2009 09:14:25 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n397EM2R002836; Thu, 9 Apr 2009 09:14:22 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Tim Polk Cc: ietf-ssh@netbsd.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 09 Apr 2009 09:14:21 +0200 In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> (Tim Polk's message of "Wed, 8 Apr 2009 09:02:00 -0400") 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 Tim Polk writes: > (1) does the exposure of the ssh packet length have significant > security implications for ssh itself? I don't think so. > (2) were applications that rely on ssh for security designed to take > advantage of the encrypted packet length? My gut feeling is that it's a good thing to be able to hide message boundaries. I do my best to take advantage of this, and try to stick to one or a few fix sizes of TCP segments, with the boundaries between TCP-segments typically in the middle of the payload of an SSH_MSG_IGNORE message. > (3) does the change in padding length calculation (caused by excluding > the packet_length from the ciphertext) impose a significant impediment > to migrating existing implementations? Supporting two different modes for the transport protocol of course iplies some additional complexity. My experience with handling of encrypted length fields is that it's not very complicated, it's about the same complexity or less as the handling of padding. I admit that I haven't done any deep thinking of attacks based on partial decryption. We're comparing these two processes: 1. Read first block, decrypt, get length field, read rest of message (if larger than one block) and mac, decrypt, check MAC. (It's of course imperative to not act on anything in the message beyond the length field until the mac is properly verified) 2. Get unencrypted length field, get rest of message, decrypt, check MAC. In the first scenario, the attacker could mount the following attack: Send a first chosen ciphertext block, then slowly send more data. Then the attacker can then find out what the first four bytes of the decrypted block are, by obserrving how much data it can send before the ssh implementation in the othher end disconnects. Actually, with high probability, it will disconnect immediately, because a length field exceeding the maximum size is a protocol error; at least that's how my implementation behave. So the setup is somewhat liek on oracle telling thhe attacker whether or not the first two bytes of the decrypted block are zero. But since (1) this is an attack only on the session key, and (2) it can be mounted only once per connection, I doubt the attacker can derive any useful information (useful would meen: Sufficient to get a little information about cleartext previously sent over the same session). And any decent block-cipher should have reasonable resistant also to a general chosen-ciphertext attack, right? Are there any other relevant attacks? Anything that's specific to AEAD (which I'm not familiar with)? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 03:37: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 2D1F63A6B12 for ; Thu, 9 Apr 2009 03:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.611, 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 4nYCkWRMRXK2 for ; Thu, 9 Apr 2009 03:37:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2407A3A6A4D for ; Thu, 9 Apr 2009 03:37:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7F04663B14C; Thu, 9 Apr 2009 10:38:12 +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 E370763B1C0 for ; Thu, 9 Apr 2009 10:38:05 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0C63C4833F7; Thu, 9 Apr 2009 22:38:01 +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 7av87JbiFsMg; Thu, 9 Apr 2009 22:38:00 +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 AAC234833EA; Thu, 9 Apr 2009 22:37:58 +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 7944F1DE4001; Thu, 9 Apr 2009 22:37:57 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lrrdt-0002Ag-B1; Thu, 09 Apr 2009 22:37:57 +1200 From: Peter Gutmann To: djm@mindrot.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Thu, 09 Apr 2009 22:37:57 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller writes: >I think any option that changes the binary packet format would need to be >included in the kex hash to prevent downgrade/upgrade attacks. This is >somewhat annoying implementation-wise if it is a separate packet. Is there any way of doing some sort of pre-auth to prevent tampering with the options packets? A problem with the rather late handling of MITM detection is that if you negotiate more secure options via SSH_MSG_OPTION and a MITM subjects you to a downgrade attack then by the time you've detected the MITM it's too late. What I mean here is that let's say there's some attack on step N of the protocol, either the protocol itself or the complexity of the implementation of certain steps. So you send an SSH_MSG_OPTION telling the peer to switch to a limited-attack-surface version of the handshake, with the exchange being: Step 1: KEYEX Step 2: OPTION ... Step N: Vulnerable part ... Step M: Detection of manipulation by MITM Since a MITM can remove the OPTION message, they leave you vulnerable at step N because you can't detect the modification until step M. I can think of a pile of Rube Goldberg hacks for this, but I'm wondering if there's a clean way to handle it. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 03:43: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 9CAB83A6A0D for ; Thu, 9 Apr 2009 03:43:46 -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=[AWL=0.000, 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 bDd7xaVdRp1w for ; Thu, 9 Apr 2009 03:43:45 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 86C373A6906 for ; Thu, 9 Apr 2009 03:43:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EABD863B1B7; Thu, 9 Apr 2009 10:44:47 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 11A4E63B12F for ; Thu, 9 Apr 2009 10:44:45 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 78A5AC4AFE; Thu, 9 Apr 2009 20:44:43 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 15F8CC4ACD; Thu, 9 Apr 2009 20:44:37 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id B5B38A4F6D; Thu, 9 Apr 2009 20:44:35 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id B3C1FA4F6C; Thu, 9 Apr 2009 20:44:35 +1000 (EST) Date: Thu, 9 Apr 2009 20:44:35 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 9 Apr 2009, Peter Gutmann wrote: > What I mean here is that let's say there's some attack on step N of the > protocol, either the protocol itself or the complexity of the implementation > of certain steps. So you send an SSH_MSG_OPTION telling the peer to switch to > a limited-attack-surface version of the handshake, with the exchange being: > > Step 1: KEYEX > Step 2: OPTION > ... > Step N: Vulnerable part > ... > Step M: Detection of manipulation by MITM > > Since a MITM can remove the OPTION message, they leave you vulnerable > at step N because you can't detect the modification until step M. A post-KEX OPTION packet could work* and I don't think it could be trivially elided by an on-path attacker - the MAC takes in the sequence number, which would be off unless the attacker had some way of replacing the packet (implying a total protocol break) and it would also desynchronise any cipher state. * except that it won't - OpenSSH just had to switch off a few channel and global extensions for all but other OpenSSH peers because some other implementations will disconnect as soon as they see an extension message that they do not recognise. So we really are quite constrained in how we can practically extend the protocol. > I can think of a pile of Rube Goldberg hacks for this, but I'm wondering if > there's a clean way to handle it. Represent binary packet protocol changes though new cipher names. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 03:51: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 08A693A6A2A for ; Thu, 9 Apr 2009 03:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 5stwxUmFrYD6 for ; Thu, 9 Apr 2009 03:51:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3217B3A6845 for ; Thu, 9 Apr 2009 03:51:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3939A63B18C; Thu, 9 Apr 2009 10:52:45 +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 0244763B186 for ; Thu, 9 Apr 2009 10:52:43 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F0B8319B3D; Thu, 9 Apr 2009 22:52:42 +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 s37gbZOG+epK; Thu, 9 Apr 2009 22:52:42 +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 53F2619B2E; Thu, 9 Apr 2009 22:52:38 +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 C92DE1DE4001; Thu, 9 Apr 2009 22:52:33 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lrrs1-0002sf-KX; Thu, 09 Apr 2009 22:52:33 +1200 From: Peter Gutmann To: nisse@lysator.liu.se, tim.polk@nist.gov Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: clonvick@cisco.com, ietf-ssh@netbsd.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, ylo@ssh.com In-Reply-To: Message-Id: Date: Thu, 09 Apr 2009 22:52:33 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >I admit that I haven't done any deep thinking of attacks based on partial >decryption. I have, and if you want to do it properly it makes the header read incredibly complicated. I've just had a look and it's about 700 lines of code to safely process the packet header with appropriate checking and whatnot, with a lot of awkward length-checking and data handling. For TLS it's maybe 150 lines of quite straightforward code (read length, check validity, read data, decrypt). I'm still not sure I trust the equivalent SSH code, despite spending way more time on it than the TLS code, because of its complexity. >Are there any other relevant attacks? I wouldn't even bother looking for a crypto weakness, I'd exploit the complexity of the code required to handle this and look for overflows, off-by- one errors, bounds checking, all the usual stuff. For that the answer is "yes, many", although it'd depend on the implementation you're going after. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 16:25: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 C871D3A6D0E for ; Thu, 9 Apr 2009 16:25:27 -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 Dt4v9rnmTzQL for ; Thu, 9 Apr 2009 16:25:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 9A8CA3A6A2F for ; Thu, 9 Apr 2009 16:25:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0B3E063B1AB; Thu, 9 Apr 2009 23:26:18 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by mail.netbsd.org (Postfix) with ESMTP id 4355063B244 for ; Thu, 9 Apr 2009 23:25:59 +0000 (UTC) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id n39CdkhX012738; Thu, 9 Apr 2009 12:39:46 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:36:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Date: Thu, 9 Apr 2009 08:36:24 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB034935@MSIS-GH1-UEA06.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm4wu+MorpFDEztSjGbh7pQO+vuJgAS5mIwAAAbUIA= From: "Igoe, Kevin M." To: "Damien Miller" , "Tim Polk" Cc: , "Tero Kivinen" , "Bill Sommerfeld" , "Chris Lonvick" , , "Jerome A. Solinas" , X-OriginalArrivalTime: 09 Apr 2009 12:36:25.0411 (UTC) FILETIME=[CBF2E130:01C9B90F] Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller writes: > 5.1/5.2 - The suggested algorithm names are structurally different to > the other algorithm identifiers used in SSH. In particular, I don't = see > any need for the "-ssh" to appear in the algorithm name as the cipher > has not been modified in any substantial way. Why not just = "aes128-gcm" > or "aes128-gcm-aead" if you wanted to be particularly verbose? AEAD has its own convention for naming algorithms. The names selected are more in keeping with the AEAD conventions. I'm not terribly fond of theses names and would be willing to modify them as needed, but I'd like to keep an "ssh" tag in the name so that when one looks at the namespace = of all AEAD algorithms, it is clear that these algorithms are intended for use in secsh. > First, why GCM? Some rationale would be nice. Adding a justification is easily done, its much the same as it is in other protocols (e.g. see draft-mcgrew-srtp-aes-gcm-01). -----Original Message----- From: Damien Miller [mailto:djm@mindrot.org] Sent: Wednesday, April 08, 2009 11:26 PM To: Tim Polk Cc: ietf-ssh@netbsd.org; Tero Kivinen; Bill Sommerfeld; Chris Lonvick; ylo@ssh.com; Igoe, Kevin M.; Jerome A. Solinas; Eronen Subject: Re: applying AES-GCM to secure shell: proposed "tweak" On Wed, 8 Apr 2009, Tim Polk wrote: > Folks, >=20 > The IESG is currently considering publication of draft-igoe-secsh-aes- > gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer > Protocol", as an Informational RFC. The draft specifies the > application of the Authenticated Encryption with Associated Data > (AEAD) block cipher mode AES Galois/Counter Mode to provide both > confidentiality and data integrity for SSH. (See RFC 5116, "An > Interface and Algorithms for Authenticated Encryption", for a general > look at AEAD algorithms and NIST Special Publication 800-38D for the > specification of the GCM mode; see URLs below.) >=20 > The draft was designed to minimize the changes to RFC 4253 (the SSH > Transport Layer Protocol), so it encrypts the whole SSH binary packet, > including the packet_length field. >=20 > However, AEAD decryption as defined in both RFC 5116 and SP 800-38D > takes the ciphertext as input, and returns either (1) the plaintext if > the authentication succeeds or (2) failure. The ciphertext here is an > octet string of known length, not an ubounded stream. >=20 > Since the packet_length field is also encrypted, SSH cannot determine > the ciphertext boundary before passing the data to AEAD decryption. > (This differs from current SSH encryption modes where the data is > first decrypted, then the packet length field is parsed, and finally > the MAC is verified.) >=20 > Two solutions have been proposed: (1) explicitly allowing "partial > decryption" so that an implementation can recover the packet_length > without authenticating the data; or (2) sending the packet_length > unencrypted so that it is always available. another option, would be encrypting the length field with an independently-keyed cipher, but I doubt that it is worth it. I'd agree that simply leaving the length fields unencrypted would be best, but the security considerations should mention the need to use padding to avoid revealing secrets, especially for password userauth. Some general comments on the draft: First, why GCM? Some rationale would be nice. 4.1 Key exchange implies modification to the matching rules, but doesn't IMO sufficiently spell out exactly how matching should occur when the GCM method appears in various positions of the client and server's = lists. 5.1/5.2 - The suggested algorithm names are structurally different to the other algorithm identifiers used in SSH. In particular, I don't see any need for the "-ssh" to appear in the algorithm name as the cipher has not been modified in any substantial way. Why not just "aes128-gcm" or "aes128-gcm-aead" if you wanted to be particularly verbose? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 16:30: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 988113A67FC for ; Thu, 9 Apr 2009 16:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.873 X-Spam-Level: X-Spam-Status: No, score=-8.873 tagged_above=-999 required=5 tests=[AWL=1.115, 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 QyJqAd-d7rpF for ; Thu, 9 Apr 2009 16:30:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 875F13A6D04 for ; Thu, 9 Apr 2009 16:30:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 075F763B1F3; Thu, 9 Apr 2009 23:31:07 +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 5F30163B196 for ; Thu, 9 Apr 2009 23:30:56 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA00095; Thu, 9 Apr 2009 15:00:44 -0400 (EDT) From: der Mouse Message-Id: <200904091900.PAA00095@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: Thu, 9 Apr 2009 14:38:14 -0400 (EDT) To: ietf-ssh@netbsd.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090409174919.GD1500@Sun.COM> References: <200904090531.BAA25375@Sparkle.Rodents-Montreal.ORG> <20090409174919.GD1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > I agree. I see no reason to deviate from using alg names for this > sort of negotiation. For this particular case? If you're proposing to use it with all, or even a large subset of, existing ciphers, I do: it avoids the cross-product problem. One option like this doubles the number of ciphers offered Each additional such binary option doubles the list size again, and an option with more than two settings multiplies it more; pretty soon you're up to offering dozens of names for each cipher supported. THe cross product problem is bad enough already with things like operating modes (_cbc, _ctr) and key sizes (aes{128,192,256}_*). If you're proposing it as a particular encryption algorithm which happens to "encrypt" the length trivially, I agree, it should be just another encryption algorithm as far as the protocol goes. In general? I disagree. There are many things which could reasonably be negotiated as options using a mechanism like this, and they don't all make sense as GLOBAL_REQUESTs. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 16:31: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 F283F3A6D18 for ; Thu, 9 Apr 2009 16:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.223, 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 SSVkbuxyPVz0 for ; Thu, 9 Apr 2009 16:31:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 694023A6B64 for ; Thu, 9 Apr 2009 16:30:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E43B663B1F4; Thu, 9 Apr 2009 23:31:16 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id EC00663B185 for ; Thu, 9 Apr 2009 23:31:13 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n39I6EU1011437 for ; Thu, 9 Apr 2009 18:06:14 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 n39I6ERa000837 for ; Thu, 9 Apr 2009 12:06:14 -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 n39HnKfx007461; Thu, 9 Apr 2009 12:49:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39HnKa4007460; Thu, 9 Apr 2009 12:49:20 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 9 Apr 2009 12:49:20 -0500 From: Nicolas Williams To: Damien Miller Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090409174919.GD1500@Sun.COM> References: <200904090531.BAA25375@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 04:50:50PM +1000, Damien Miller wrote: > On Wed, 8 Apr 2009, der Mouse wrote: > > > I would suggest creating new packet type for negotiating options like > > this. As a strawman: > > > > byte SSH_MSG_OPTION (value = 7) > > string option name > > ... option-specific data > > I think any option that changes the binary packet format would need > to be included in the kex hash to prevent downgrade/upgrade attacks. > This is somewhat annoying implementation-wise if it is a separate packet. I agree. I see no reason to deviate from using alg names for this sort of negotiation. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 16:41:05 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 9E8693A6C51 for ; Thu, 9 Apr 2009 16:41:05 -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 HLwIJsGd0r1B for ; Thu, 9 Apr 2009 16:41:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2FFF03A6B2E for ; Thu, 9 Apr 2009 16:40:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4ACB663B1B5; Thu, 9 Apr 2009 23:42:01 +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 75F2763B19F for ; Thu, 9 Apr 2009 23:41:58 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 600F040002; Thu, 9 Apr 2009 13:59:25 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 53B3A400A3; Thu, 9 Apr 2009 13:59:25 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 2747740002; Thu, 9 Apr 2009 13:59:25 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n39BxZZu013181; Thu, 9 Apr 2009 13:59:35 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n39BxVdh013180; Thu, 9 Apr 2009 13:59:31 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Peter Gutmann Cc: tim.polk@nist.gov, clonvick@cisco.com, ietf-ssh@netbsd.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 09 Apr 2009 13:59:30 +0200 In-Reply-To: (Peter Gutmann's message of "Thu, 09 Apr 2009 22:52:33 +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: > I have, and if you want to do it properly it makes the header read incredibly > complicated. What I do is basically that I check that the length doesn't exceed the maximum message size, and that the padding length abides the rules in the spec (these checks examine the first 5 bytes of the decrypted first block). I'd do the same checks if length and/or padding were unencrypted. Besides this, nothing interesting is done to the packet data until the complete packet is read. If this is not the "proper" way of doing it, I'd appreciate a hint of what other checks are needed and why. I may well be missing something. > I've just had a look and it's about 700 lines of code to safely > process the packet header with appropriate checking and whatnot, with a lot of > awkward length-checking and data handling. I simply don't get this. I'm now looking at the corresponding functions in (the development version of) lsh. There's one function that handles the reading of transport packets, including processing of the message header in the first block, and it is 165 lines (including some i/o and some debugging code), and a second function that applies the current crypto, mac and decompression algorithms to a complete packet, which is 64 lines more. Code in question is the functions decode_packet and transport_read_packet in http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/*checkout*/lsh/src/transport_read.c?content-type=text%2Fplain&root=lsh Sure, there's some extra book-keeping for handling the first block, but I don't understand how that could amount to many hundreds of lines of code. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 16:59: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 43CEB3A6D1A for ; Thu, 9 Apr 2009 16:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.958 X-Spam-Level: X-Spam-Status: No, score=-8.958 tagged_above=-999 required=5 tests=[AWL=1.030, 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 36wFxdWfb5Hk for ; Thu, 9 Apr 2009 16:59:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 570323A6D18 for ; Thu, 9 Apr 2009 16:59:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3E78C63B172; Fri, 10 Apr 2009 00:00:57 +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 3863963B165 for ; Fri, 10 Apr 2009 00:00:54 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA28977; Thu, 9 Apr 2009 12:28:52 -0400 (EDT) From: der Mouse Message-Id: <200904091628.MAA28977@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: Thu, 9 Apr 2009 12:22:22 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> * except that it won't - OpenSSH just had to switch off a few >> channel and global extensions for all but other OpenSSH peers >> because some other implementations will disconnect as soon as they >> see an extension message that they do not recognise. > This is really unfortunate, given that RFC4253 is quite clear on how > unrecognized extensions must be handled. I would propose that we > solve this problem once and for all by using a _single_ "magic" > cipher name, or possibly a magic cookie in the version banner > comments, to indicate that unrecognized messages are handled > correctly and/or that option negotiation is supported. That's a good one, right up there with RFC 3514. (For those who don't get Jeff's humour: what's to prevent buggy implementations of the "yes I get this right" claim?) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:00: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 EB0ED3A6D16 for ; Thu, 9 Apr 2009 17:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.032 X-Spam-Level: X-Spam-Status: No, score=-9.032 tagged_above=-999 required=5 tests=[AWL=0.956, 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 X4qgPQ-IwvpS for ; Thu, 9 Apr 2009 17:00:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CA2603A6BB6 for ; Thu, 9 Apr 2009 17:00:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8D15163B118; Fri, 10 Apr 2009 00:01:05 +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 9957C63B165 for ; Fri, 10 Apr 2009 00:00:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id MAA28872; Thu, 9 Apr 2009 12:22:11 -0400 (EDT) From: der Mouse Message-Id: <200904091622.MAA28872@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: Thu, 9 Apr 2009 12:01:06 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > With regard to the negotiation itself, I think it might be cleaner to > have three separate messages: [...] That would work too. I was trying to conserve (scarce) message number space by using a single message number with the distinction conveyed by your three messages being part of the option negotiation, but this looks sufficiently general it'd be OK too. (And options which really need more elaborate negotiation can always make REQUEST and REPLY rubber-stamps and do the real work with DATA.) One thing is not clear from this: is option support negotiated separately in each direction? If not, what happens if two REQUEST packets for the same option, one in each direction, cross in flight? (It seems to me most ssh-like to negotiate separately in each direction. This means two packets each way instead of one, but they are streamable packets, so I don't see that as a big deal.) Oh, the spec also needs to define what SSH_MSG_UNIMPLEMENTED means in response to these. Presumably this counts as a nak reply when in response to _REQUEST and a protocol error for the other two, but it needs to be stated. > In the case of the cleartext-packet-lengths option, the option data > in the _REQUEST must be empty, and any implemention supporting the > option MUST respond to the _REQUEST with an ack; that is, the nak > response may not be sent for this option. [...] The side sending the > _REPLY message may begin using cleartext lengths immediately by > including option data of "on" in the _REPLY packet. This makes it sound as though you're assuming option support is not negotiated separately in each direction. > Once the option has been negotiated, either side may switch between > sending cleartext and encrypted lengths whenever it wants, by sending > SSH_MSG_OPTION_DATA with option "cleartext-packet-lengths" and data > "on" to indicate lengths will be cleartext starting with the next > packet, or "off" to indicate they will be encrypted (when encryption > is in effect). > I think this is cleaner than the approach der Mouse suggested, Yes, I think I agree. It's certainly simpler; since I think it's also sufficient for the task, that makes it cleaner. :) > because it allows either side to switch modes at any time and makes > it clear what the new mode will be on every switch. It does this at > the expense of eliminating the ability of the peer to accept or > reject any mode change, instead requiring that once the option has > been negotiated, each peer be willing to accept either encrypted or > unencrypted lengths at any time (though an encryption algorithm may > require the option be enabled). What happens if such an encryption algorithm is in use and the implementation receives a _DATA/"off" packet? (Yes, it would be a strange thing for an implementation to send, but I think it needs to be addressed, even if only with a "this is a protocol error from which no recovery is specified" remark in the encryption algorithm definition.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:00: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 08A643A6C4C for ; Thu, 9 Apr 2009 17:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.096 X-Spam-Level: X-Spam-Status: No, score=-9.096 tagged_above=-999 required=5 tests=[AWL=0.892, 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 4ukbRI9KO9S6 for ; Thu, 9 Apr 2009 17:00:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CB2CD3A6BB6 for ; Thu, 9 Apr 2009 17:00:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5738363B165; Fri, 10 Apr 2009 00:01: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 ACCF763B1B4 for ; Fri, 10 Apr 2009 00:01:08 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA28713; Thu, 9 Apr 2009 11:58:39 -0400 (EDT) From: der Mouse Message-Id: <200904091558.LAA28713@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: Thu, 9 Apr 2009 11:38:39 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <98842F916ED550B63C6C1860@atlantis.pc.cs.cmu.edu> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> <200904090008.UAA23669@Sparkle.Rodents-Montreal.ORG> <98842F916ED550B63C6C1860@atlantis.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> Also, I just reread section 6 of 4253, and I can't find anything >> that says the ciphertext from an encryption algorithm has to be the >> same size as the plaintext, so you could always just save the >> length, replace it with four random bytes, encrypt as normal, and >> prepend the saved length. (Decryption, of course, just throws away >> the four random bytes.) > I think what you're effectively suggesting here is that the transport > layer pad to the "wrong" size (since the length is included but will > not be encrypted), and then the encryption algorithm add extra > "hidden" padding to pad it to the right length. Yes, I think that's a fair rephrasing of my suggestion. > I think that could work, but note that the number of bytes of > ciphertext must be exactly equal to four plus the "decrypted" length > value, since the latter is the only indication of how many bytes the > transport layer should read out of the TCP stream. Putting it that way reveals, perhaps, part of the problem. There is no particular reason why the code that reads data from the wire data stream (usually but not necessarily TCP) has to know where packet boundaries are. As long as every packet boundary falls at a place such that the data->encryption->decryption->data pipeline can deliver the whole packet without needing more input data (which is the point of padding to a multiple of the blocksize), the protocol can work. This does mean that implementations which expect to issue wire data stream reads for exactly the right amount of data early in packet processing will be constrained in what encryption algorithms they implement, though as far as I know no algorithms which would make that a practical constraint are implemented for ssh (and my suggestion above is not one, since the encryption algorithm layer can provide the wire length early). At the very worst, implementations may need internal rework if they want to implement the new stuff. > There are likely implementations which expect the "decrypted" length > to also be the length of the plaintext packet (not counting the > packet_length and mac), which would have to change. > OTOH, I would expect support for AEAD-mode ciphers to make it > necessary for the plaintext and ciphertext to be different sizes > anyway, so this shouldn't be a major change. Yes, there are doubtless implementations which assume that encrypted and cleartext are the same size. They will need internal rework if they are to implement any of this stuff, but I don't see that as a reason to twist the design uncomfortably; it just means implementing it for them, if done at all, will be more work. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:00: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 94F833A6C4C for ; Thu, 9 Apr 2009 17:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.151 X-Spam-Level: X-Spam-Status: No, score=-9.151 tagged_above=-999 required=5 tests=[AWL=0.837, 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 BdUTPpsrEPKa for ; Thu, 9 Apr 2009 17:00:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A17673A6BB6 for ; Thu, 9 Apr 2009 17:00:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7EA7763B1BC; Fri, 10 Apr 2009 00:01:18 +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 4EAAF63B170 for ; Fri, 10 Apr 2009 00:01:03 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA28569; Thu, 9 Apr 2009 11:35:07 -0400 (EDT) From: der Mouse Message-Id: <200904091535.LAA28569@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: Thu, 9 Apr 2009 10:54:36 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> I admit that I haven't done any deep thinking of attacks based on >> partial decryption. > I have, and if you want to do it properly it makes the header read > incredibly complicated. I've just had a look and it's about 700 > lines of code to safely process the packet header with appropriate > checking and whatnot, with a lot of awkward length-checking and data > handling. For TLS it's maybe 150 lines of quite straightforward code > (read length, check validity, read data, decrypt). Oddly enough, "read length, check validity, read data" is what moussh's packet length handling looks like. Perhaps the code you were reading was so Byzantine because it was using an encryption interface that was not well suited to the task? My code for decrypting, reading packet length, checking, handling compression and MAC, and passing off to the protocol stack, is about 131 lines[%]. It calls out to the encryption and compression implementations, but the lower layers it calls are completely blind to the binary packet format; they don't know anything about ssh's "length, padding length, payload, padding, MAC" packet structure, so I don't consider it unreasonable to not include their line count. (Actually, I get close to 700 lines if I _do_ include the next layer down - the encryption algorithm glue layer runs from 94 (IDEA) to 265 (Rinjdael) lines, and the zlib glue layer is 364 lines.) [%] Lines 127 to 258 of ftp.rodents-montreal.org:/mouseware/local-src/moussh/moussh-20090319/bpp.c are the code in question. > I wouldn't even bother looking for a crypto weakness, I'd exploit the > complexity of the code required to handle this and look for > overflows, off-by-one errors, bounds checking, all the usual stuff. > For that the answer is "yes, many", although it'd depend on the > implementation you're going after. Certainly. But if the code is really 700 lines, either a lot of unrelated stuff is getting caught up in the line count or someone is doing something very wrong. It does not need to be that elaborate. Not that I claim my code is perfect - if you do happen to notice any mistakes in it, I'd be interested to hear, of course. But runs and interoperates with other implementations, so I can't have left out any really major pieces. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:00:32 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 2265D3A6C4C for ; Thu, 9 Apr 2009 17:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.506 X-Spam-Level: X-Spam-Status: No, score=-7.506 tagged_above=-999 required=5 tests=[AWL=-0.907, 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 QRYvOrg7NyRo for ; Thu, 9 Apr 2009 17:00:31 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id 619E53A6BB6 for ; Thu, 9 Apr 2009 17:00:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1D7B863B1C1; Fri, 10 Apr 2009 00:01:21 +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 A683663B133 for ; Fri, 10 Apr 2009 00:01:11 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA28225; Thu, 9 Apr 2009 10:37:50 -0400 (EDT) From: der Mouse Message-Id: <200904091437.KAA28225@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: Thu, 9 Apr 2009 10:33:52 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> I think any option that changes the binary packet format would need >> to be included in the kex hash to prevent downgrade/upgrade attacks. >> This is somewhat annoying implementation-wise if it is a separate >> packet. > Is there any way of doing some sort of pre-auth to prevent tampering > with the options packets? You could simply decree that options packets for the option in question are not acceptable if sent before the first kex completes. (I'd hesitate to do that for all options packets, but it may be necessary.) > A problem with the rather late handling of MITM detection is that if > you negotiate more secure options via SSH_MSG_OPTION and a MITM > subjects you to a downgrade attack then by the time you've detected > the MITM it's too late. Too late for what? You need to be careful to send nothing important until after MitM detection, but if you are then what's the risk? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:01: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 E37413A6BB6 for ; Thu, 9 Apr 2009 17:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.456 X-Spam-Level: X-Spam-Status: No, score=-7.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 9psi15fjPkWX for ; Thu, 9 Apr 2009 17:01:04 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id 3EED63A6B78 for ; Thu, 9 Apr 2009 17:00:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E34C63B1A8; Fri, 10 Apr 2009 00:01:27 +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 15BC263B1BF for ; Fri, 10 Apr 2009 00:01:16 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA28319; Thu, 9 Apr 2009 10:54:29 -0400 (EDT) From: der Mouse Message-Id: <200904091454.KAA28319@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: Thu, 9 Apr 2009 10:38:04 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > A post-KEX OPTION packet could work* [...] > * except that it won't - OpenSSH just had to switch off a few channel > and global extensions for all but other OpenSSH peers because some > other implementations will disconnect as soon as they see an > extension message that they do not recognise. OpenSSH didn't _have_ to. It _chose_ to. Broken implementations are broken; if they can't be bothered to correctly respond to well-defined and conformant protocol they don't happen to implement, that's their problem. If OpenSSH really wants to bend over backwards to avoid showing up bugs in buggy implementations, surely the right way to do it is by detecting the buggy ones and working around them, rather than assuming everyone but themselves is buggy. If I create and release an implementation that ungracefully disconnects when offered anything but 3des-cbc as a cipher, will they then stop offering everything else unless talking to themselves? One that crashes when offered a username containing a 'q', will they then reject attempts to use such usernames? They're basically the same thing, just a little (first one) or a lot (second one) more extreme. You can't paper over everyone else's bugs, and trying only encourages the bugs to persist. > So we really are quite constrained in how we can practically extend > the protocol. Only if you really do believe in breaking interoperability with non-broken implementations for the sake of interoperability with broken implementations. I don't. I ran into an implementation apparently too broken to handle some one of the extensions moussh uses (I don't know which extension - it was the embedded ssh server on a switch, and the tradeoffs were wrong for trying to probe the envelope of the bug). But what I did was to suppress all use of DNS-based extension names when given a command-line flag saying to do so, not to do so by default! /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:21: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 EAA373A657C for ; Thu, 9 Apr 2009 17:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Hzhd275QtDcM for ; Thu, 9 Apr 2009 17:21:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D3AA83A6358 for ; Thu, 9 Apr 2009 17:20:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D797E63B170; Fri, 10 Apr 2009 00:21:43 +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 3479B63B140 for ; Fri, 10 Apr 2009 00:21:39 +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 4776721; Thu, 09 Apr 2009 13:50:57 -0600 Message-ID: <49DE51A1.6020602@vandyke.com> Date: Thu, 09 Apr 2009 13:50:57 -0600 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Gutmann CC: Nicolas.Williams@sun.com, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, jhutz@cmu.edu, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Peter Gutmann wrote: > Nicolas Williams writes: > > >> Er, actually, I'm not sure. It depends on what implementations do with it >> now when it's not set to 0. Hmmm, what does the spec say to do about that >> field? Sadly: nothing, at least not in section 7.1. >> > > Well if it's RFU then it's implied that you ignore it, which has been the > practice for RFU fields since at least the 1970s (in things like status flags > registers), and probably even earlier but I wasn't playing with computer > hardware back then. > > How about a quick straw poll, since we've probably got a good number of > implemeters here. If your implementation sees a non-zero value in the RFU > field, will it: > > 1. Ignore it and continue, since it's RFU. > 2. Run Nethack, and failing that, emacs in Towers-of-Hanoi mode. > 3. Reformat the hard drive. > 4. ??? > 5. Profit. > > Peter. > And as for our implementation, it will ASSERT() for debug builds (which we don't ship so it isn't a big deal) and ignore the value in release builds. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:28: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 477323A67FC for ; Thu, 9 Apr 2009 17:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=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 RbyzlbO1Fzpa for ; Thu, 9 Apr 2009 17:28:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id F06943A6358 for ; Thu, 9 Apr 2009 17:28:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 30A3963B17D; Fri, 10 Apr 2009 00:29:36 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp7.xenetic.net (smtp7.xenetic.net [80.88.176.189]) (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 51ECF63B12F for ; Fri, 10 Apr 2009 00:29:33 +0000 (UTC) Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp7.xenetic.net (8.14.3/8.14.3) with ESMTP id n39HKXqB027027; Thu, 9 Apr 2009 20:20:33 +0300 Received: from [10.1.254.253] ([10.1.254.253]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 20:20:32 +0300 Message-ID: <49DE2E60.3030102@ssh.com> Date: Thu, 09 Apr 2009 20:20:32 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Damien Miller CC: Peter Gutmann , jhutz@cmu.edu, Nicolas.Williams@sun.com, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2009 17:20:32.0492 (UTC) FILETIME=[7CCD02C0:01C9B937] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4,1.2.40,4.0.166 definitions=2009-04-09_14:2009-04-09,2009-04-09,2009-04-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904090119 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller wrote: > On Thu, 9 Apr 2009, Peter Gutmann wrote: > >> Nicolas Williams writes: >> >>> [So far the only extensibility mechanisms that we have at that point in the >>> protocol are: new protocol version number (not going to happen) and magic >>> algorithm names (which have been used successfully).] >> ... and the completely unused 32-bit flags field in the first message, which I >> mentioned previously :-). > > I think it would be much safer to define new cipher names for this. I agree. I think that most straightforward idea would be to allocate cipher names to selected gcm ciphers so that if such cipher gets selected, it will have side-effects to packet format that will be in effect after the subsequent NEWKEYS packet. I don't support an idea to add some kind of "*" magic in order to offer gcm functionality over the existing algorithms (proposed by Kivinen). I also think that using an independent cipher to encrypt packet lengths is not worth impelemting. Replacing cipher+mac with gcmcipher+cipher is just not worth it. Actualy quite a few problems have arisen earlier from the fact that SecSh has encrypted packet length fields (which TLS doesn't have). However simply omitting packet length encryption would also require very careful consideration, because of various potential authentication related issues (password length snooping etc.). I will think about this in more detail next week and try to think some way around the obvious caveats. -- Timo J. Rinne Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 17:48: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 9351D3A6C9E for ; Thu, 9 Apr 2009 17:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.105 X-Spam-Level: X-Spam-Status: No, score=-9.105 tagged_above=-999 required=5 tests=[AWL=0.883, 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 SuVc6T+DgzMY for ; Thu, 9 Apr 2009 17:48:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B84D83A6BDD for ; Thu, 9 Apr 2009 17:48:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2066163B133; Fri, 10 Apr 2009 00:49:23 +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 BE79563B1EC for ; Fri, 10 Apr 2009 00:49:20 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id UAA02426; Thu, 9 Apr 2009 20:49:19 -0400 (EDT) From: der Mouse Message-Id: <200904100049.UAA02426@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: Thu, 9 Apr 2009 20:47:08 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <49DE51A1.6020602@vandyke.com> References: <49DE51A1.6020602@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > How about a quick straw poll, since we've probably got a good number > of implemeters here. If your implementation sees a non-zero value in > the RFU field, will it: Ignore it. (I've been considering warning and disconnecting as other possible reactions, but haven't seen any compelling reason to prefer one over another. Perhaps it's time for another configuration parameter - a little difficult to test, though.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 18:12: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 D44B728C107 for ; Thu, 9 Apr 2009 18:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=-3.799, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MANGLED_FROM=2.3, MIME_QP_LONG_LINE=1.396] 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 fB2siv5QTk9l for ; Thu, 9 Apr 2009 18:12:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B3E7F28C0F4 for ; Thu, 9 Apr 2009 18:12:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0705363B236; Fri, 10 Apr 2009 01:13:38 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) (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 57DA163B235 for ; Fri, 10 Apr 2009 01:13:36 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n39FERfm018077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 11:14:27 -0400 (EDT) Date: Thu, 09 Apr 2009 11:14:27 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <98842F916ED550B63C6C1860@atlantis.pc.cs.cmu.edu> In-Reply-To: <200904090008.UAA23669@Sparkle.Rodents-Montreal.ORG> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> <200904090008.UAA23669@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.117 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 08, 2009 07:28:45 PM -0400 der Mouse=20 wrote: >>> [F]rom what I've gathered from the list, this could, as far as the >>> core protocol is concerned, be seen as an encryption algorithm that >>> happens to produce ciphertext identical to the plaintext for certain >>> parts of the data stream. >> I wouldn't have a problem with that, but it's not actually the case. >> The base protocol spec assumes that encryption algorithms have a >> block size, and requires that the amount of padding be chosen such >> that the combined size of the length, padding length, padding, and >> payload be a multiple of the block size. > > Right - with an artificial block size imposed for stream ciphers. > (Actually, the wording in RFC4253 is not very good; consider what an > implementer reading the "Note that the..." paragraph beginning ten or > so lines into page 8 would do with a cipher using 7-byte blocks.) I read that paragraph as normative, and having the effect that SSH cannot=20 operate with ciphers having a block size of 3, 5, 6, or 7 bytes. If you=20 really wanted to use such a cipher, the document describing its use with=20 SSH would have to artificially increase the "block size" to something=20 larger than 8 bytes. >> Moving the length out of the encrypted part requires changing this >> behavior. > > Why? As far as I can see, this is so only if (a) the underlying cipher > has a block size that's not a divisor of 4 bytes and (b) you insist on > na=C3=AFvely treating all the sent-encrypted data as a single data stream > for the encryption engine. OK, I'll grant that it's not necessary when using a stream cipher, or a=20 block cipher with a block size of 1, 2, or 4 bytes. But I don't think=20 there are any of the latter. > It would be very easy, for example, to use arcfour (or any other stream > cipher) to encrypt all but the length. Also, I just reread section 6 > of 4253, and I can't find anything that says the ciphertext from an > encryption algorithm has to be the same size as the plaintext, so you > could always just save the length, replace it with four random bytes, > encrypt as normal, and prepend the saved length. (Decryption, of > course, just throws away the four random bytes.) I think what you're effectively suggesting here is that the transport layer = pad to the "wrong" size (since the length is included but will not be=20 encrypted), and then the encryption algorithm add extra "hidden" padding to = pad it to the right length. I think that could work, but note that the number of bytes of ciphertext=20 must be exactly equal to four plus the "decrypted" length value, since the=20 latter is the only indication of how many bytes the transport layer should=20 read out of the TCP stream. There are likely implementations which expect=20 the "decrypted" length to also be the length of the plaintext packet (not=20 counting the packet_length and mac), which would have to change. OTOH, I would expect support for AEAD-mode ciphers to make it necessary for = the plaintext and ciphertext to be different sizes anyway, so this=20 shouldn't be a major change. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 18:13: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 9B91028C107 for ; Thu, 9 Apr 2009 18:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 wZcOri-nUI1m for ; Thu, 9 Apr 2009 18:13:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1CD3D28C0F0 for ; Thu, 9 Apr 2009 18:13:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0A0DB63B221; Fri, 10 Apr 2009 01:14:18 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) (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 44BA263B1E3 for ; Fri, 10 Apr 2009 01:14:14 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n39FgtFg019435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 11:42:56 -0400 (EDT) Date: Thu, 09 Apr 2009 11:42:55 -0400 From: Jeffrey Hutzelman To: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: References: 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.201.117 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 06:03:29 PM +1200 Peter Gutmann wrote: >> SSH_MSG_OPTION may be sent at any time, except that specific option >> definitions may impose additional restrictions for packets naming that >> option. > > Ugh, I would restrict this to specific places, e.g. right after the > KEXINIT and and couple of other well-defined redezvous points, not at any > time. If you allow either side to set protocol behaviour-changing > options at any point you're going to end up with a huge interop headache. No, I think the right thing is for the SSH_MSG_OPTION message itself to be permitted at any time, and leave it to the definitions of individual options to specify when an option may be negotiated and when the results of that negotiation take effect. FWIW, while there's nothing wrong protocol-wise with negotiating the cleartext-packet-lengths option immediately after KEXINIT, I think it's cleaner (and probably easier for some implementations) to do it just _before_ KEXINIT. After all, you probably don't want to renegotiate the option every time a new key exchange happens, but it does have to be negotiated before NEWKEYS, since some encryption algorithms will only work with plaintext lengths. With regard to the negotiation itself, I think it might be cleaner to have three separate messages: byte SSH_MSG_OPTION_REQUEST (value = 7) string option name ... option-specific data byte SSH_MSG_OPTION_REPLY (value = 8) string option name string response ... option-specific data byte SSH_MSG_OPTION_DATA (value = 9) string option name ... option-specific data _REQUEST is used to request support for an option, with optional option-specific data. _REPLY is sent in response to _REQUEST; it identifies the option in question and gives one of the following responses: "ack" - The option is supported and has now been successfully negotiated. Its features may be used immeiately, by the sender of the _REPLY starting with its next packet, and by the receiver of the _REPLY as soon as it has seen the ack. Note that an option like cleartext-packet-lengths makes a non-self-describing change to the packet format and so will still require an indicator. "nak" - The option is supported but negotiation failed, presumably because option-specific parameters proposed by the requestor are not acceptable. The option-specific data may carry information that would help a later attempt succeed. "unimplemented" - The option is unrecognized or not supported. Once an option has been successfully negotiated (i.e. _REPLY with ack), additional option-specific data may be sent in either direction according to the _DATA message; this is basically a mechanism to allow options to define new packet types without allocating message numbers. The above may still be slightly too complex, but I'm not sure how to simplify it without losing too much generality. Suggestions welcome. In the case of the cleartext-packet-lengths option, the option data in the _REQUEST must be empty, and any implemention supporting the option MUST respond to the _REQUEST with an ack; that is, the nak response may not be sent for this option. Once the option has been negotiated, either side may switch between sending cleartext and encrypted lengths whenever it wants, by sending SSH_MSG_OPTION_DATA with option "cleartext-packet-lengths" and data "on" to indicate lengths will be cleartext starting with the next packet, or "off" to indicate they will be encrypted (when encryption is in effect). The side sending the _REPLY message may begin using cleartext lengths immediately by including option data of "on" in the _REPLY packet. I think this is cleaner than the approach der Mouse suggested, because it allows either side to switch modes at any time and makes it clear what the new mode will be on every switch. It does this at the expense of eliminating the ability of the peer to accept or reject any mode change, instead requiring that once the option has been negotiated, each peer be willing to accept either encrypted or unencrypted lengths at any time (though an encryption algorithm may require the option be enabled). It does still allow cleartext lengths to be negotiated separately in each direction, which I think is appropriate given that SSH requires negotiation of encryption algorithms separately in each direction. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 18:13: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 3D32528C114 for ; Thu, 9 Apr 2009 18:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-1.305, 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 JAblIlxEcM+8 for ; Thu, 9 Apr 2009 18:13:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0A98128C0F0 for ; Thu, 9 Apr 2009 18:13:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9104A63B235; Fri, 10 Apr 2009 01:14:32 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) (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 940BB63B1E3 for ; Fri, 10 Apr 2009 01:14:29 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n39FltiB019613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 11:47:57 -0400 (EDT) Date: Thu, 09 Apr 2009 11:47:55 -0400 From: Jeffrey Hutzelman To: Damien Miller , Peter Gutmann cc: mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: References: 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.201.117 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 08:44:35 PM +1000 Damien Miller wrote: > On Thu, 9 Apr 2009, Peter Gutmann wrote: > >> What I mean here is that let's say there's some attack on step N of the >> protocol, either the protocol itself or the complexity of the >> implementation of certain steps. So you send an SSH_MSG_OPTION telling >> the peer to switch to a limited-attack-surface version of the handshake, >> with the exchange being: >> >> Step 1: KEYEX >> Step 2: OPTION >> ... >> Step N: Vulnerable part >> ... >> Step M: Detection of manipulation by MITM >> >> Since a MITM can remove the OPTION message, they leave you vulnerable >> at step N because you can't detect the modification until step M. > > A post-KEX OPTION packet could work* and I don't think it could be > trivially elided by an on-path attacker - the MAC takes in the sequence > number, which would be off unless the attacker had some way of replacing > the packet (implying a total protocol break) and it would also > desynchronise any cipher state. > > * except that it won't - OpenSSH just had to switch off a few channel and > global extensions for all but other OpenSSH peers because some other > implementations will disconnect as soon as they see an extension message > that they do not recognise. So we really are quite constrained in how we > can practically extend the protocol. This is really unfortunate, given that RFC4253 is quite clear on how unrecognized extensions must be handled. I would propose that we solve this problem once and for all by using a _single_ "magic" cipher name, or possibly a magic cookie in the version banner comments, to indicate that unrecognized messages are handled correctly and/or that option negotiation is supported. I'm wary of using separate cipher names to negotiate every possible extension, because it has the potential to cause an explosion of cipher names and the length of the lists in the KEXINIT message is limited. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 18:14: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 1545C28C0F0 for ; Thu, 9 Apr 2009 18:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.877 X-Spam-Level: X-Spam-Status: No, score=-3.877 tagged_above=-999 required=5 tests=[AWL=-1.278, 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 mcYwPl4r1mQz for ; Thu, 9 Apr 2009 18:14:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0446A28C111 for ; Thu, 9 Apr 2009 18:14:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A3EAA63B230; Fri, 10 Apr 2009 01:15:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) (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 7A75463B162 for ; Fri, 10 Apr 2009 01:15:03 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n39DC9dF013013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 09:12:10 -0400 (EDT) Date: Thu, 09 Apr 2009 09:12:09 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Peter Gutmann cc: clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <669E8C3BB20DCC434A461573@atlantis.pc.cs.cmu.edu> In-Reply-To: <20090409035749.GX1500@Sun.COM> References: <20090408223914.GU1500@Sun.COM> <20090409035749.GX1500@Sun.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.201.117 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 08, 2009 10:57:49 PM -0500 Nicolas Williams wrote: > On Thu, Apr 09, 2009 at 03:51:35PM +1200, Peter Gutmann wrote: >> Nicolas Williams writes: >> >> > [So far the only extensibility mechanisms that we have at that point >> > in the protocol are: new protocol version number (not going to happen) >> > and magic algorithm names (which have been used successfully).] >> >> ... and the completely unused 32-bit flags field in the first message, >> which I mentioned previously :-). > > This: > > uint32 0 (reserved for future extension) > > ? > > Yes, that could be used too. I admit we haven't left ourself much room for pre-keyex negotiation, but there is some. In addition to the bits already mentioned, we can use magic token in the "comments" field of the version banner, and there are also several unused messages in both the transport-generic and algorithm-negotiation layers, which implementations are REQUIRED to ignore except for sending an SSH_MSG_UNIMPLEMENTED (see RFC4253 11.4) -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 18:20:36 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 BF76328C119 for ; Thu, 9 Apr 2009 18:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 4r+5xUBL5MDZ for ; Thu, 9 Apr 2009 18:20:36 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B8A6C3A6880 for ; Thu, 9 Apr 2009 18:20:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0403F63B23A; Fri, 10 Apr 2009 01:21:40 +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 EE68863B25D for ; Fri, 10 Apr 2009 01:21:38 +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 4776720; Thu, 09 Apr 2009 13:49:24 -0600 Message-ID: <49DE5144.10408@vandyke.com> Date: Thu, 09 Apr 2009 13:49:24 -0600 From: Joseph Galbraith User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Peter Gutmann CC: Nicolas.Williams@sun.com, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, jhutz@cmu.edu, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@sun.com, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Peter Gutmann wrote: > Nicolas Williams writes: > > >> Er, actually, I'm not sure. It depends on what implementations do with it >> now when it's not set to 0. Hmmm, what does the spec say to do about that >> field? Sadly: nothing, at least not in section 7.1. >> > > Well if it's RFU then it's implied that you ignore it, which has been the > practice for RFU fields since at least the 1970s (in things like status flags > registers), and probably even earlier but I wasn't playing with computer > hardware back then. > > How about a quick straw poll, since we've probably got a good number of > implemeters here. If your implementation sees a non-zero value in the RFU > field, will it: > > 1. Ignore it and continue, since it's RFU. > 2. Run Nethack, and failing that, emacs in Towers-of-Hanoi mode. > 3. Reformat the hard drive. > 4. ??? > 5. Profit. > Last time we discussed this (extending the transport layer) I'm pretty sure we had one implementor claiming that for 'paranoia', they were checking that the value was zero. Can't remember who though. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 19:13:49 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 413B23A6D20 for ; Thu, 9 Apr 2009 19:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.748, 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 1JxyoMCB-XfO for ; Thu, 9 Apr 2009 19:13:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 237FB3A68D6 for ; Thu, 9 Apr 2009 19:13:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 42F8163B268; Fri, 10 Apr 2009 02:14:49 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 6198463B2A5 for ; Fri, 10 Apr 2009 02:14:47 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A2EhO2004200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 22:14:43 -0400 (EDT) Date: Thu, 09 Apr 2009 22:14:42 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: <200904091622.MAA28872@Sparkle.Rodents-Montreal.ORG> References: <200904091622.MAA28872@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 12:01:06 PM -0400 der Mouse wrote: > One thing is not clear from this: is option support negotiated > separately in each direction? If not, what happens if two REQUEST > packets for the same option, one in each direction, cross in flight? > (It seems to me most ssh-like to negotiate separately in each > direction. This means two packets each way instead of one, but they > are streamable packets, so I don't see that as a big deal.) Good question. I was thinking originally in terms of an option either being supported or not, separately from the question of whether any of its optional effects are enabled. An option being supported might mean something like "we can use cleartext lengths", with actually _doing_ so turned on separately for each direction, or "new packet type XXX is supported", with any interesting effects resulting from actually using the new packet type. In which case, it doesn't need to be negotiated separately for each direction, and REQUESTS crossing in flight are harmless. Of course, adding option-specific data in the REQUEST/REPLY messages complicates that, since the point of doing so is to allow negotiation of option parameters, and depending on the option that probably wants to be done separately for each direction. > Oh, the spec also needs to define what SSH_MSG_UNIMPLEMENTED means in > response to these. Presumably this counts as a nak reply when in > response to _REQUEST and a protocol error for the other two, but it > needs to be stated. In response to _REQUEST, it means the same as an "unimplemented" _REPLY, but with the additional connotation that the requestor need not bother sending any further _REQUEST messages for any option. Or, we could just declare it a protocol error in all three cases, on the grounds that we know things don't handle unimplemented messages correctly and thus we have to negotiate the presence of option negotiation. :-( >> In the case of the cleartext-packet-lengths option, the option data >> in the _REQUEST must be empty, and any implemention supporting the >> option MUST respond to the _REQUEST with an ack; that is, the nak >> response may not be sent for this option. [...] The side sending the >> _REPLY message may begin using cleartext lengths immediately by >> including option data of "on" in the _REPLY packet. > > This makes it sound as though you're assuming option support is not > negotiated separately in each direction. Yes, that's what I'm assuming. If you negotiate it separately for each direction, then only one side gains the ability to turn it on (either the sender of the REQUEST or of the REPLY, depending on whether the REQUEST means "I want to send cleartext lengths" or "I want you to send me cleartext lengths", and the reverse direction requires completing the negotiation in that direction. >> because it allows either side to switch modes at any time and makes >> it clear what the new mode will be on every switch. It does this at >> the expense of eliminating the ability of the peer to accept or >> reject any mode change, instead requiring that once the option has >> been negotiated, each peer be willing to accept either encrypted or >> unencrypted lengths at any time (though an encryption algorithm may >> require the option be enabled). > > What happens if such an encryption algorithm is in use and the > implementation receives a _DATA/"off" packet? (Yes, it would be a > strange thing for an implementation to send, but I think it needs to be > addressed, even if only with a "this is a protocol error from which no > recovery is specified" remark in the encryption algorithm definition.) I think it should be an error to advertise such an algorithm if the option has not already been negotiated. Once the option has been negotiated, we can either make it an error for it to be off while such an algorithm is in use, or specify that negotiating such an algorithm automatically turns it on and silently prevents it being turned off, or that when such an algorithm is in use cleartext lengths are always sent even when the option is in the "off" state. The advantage of the last is that when rekeying, one can select a new algorithm that does not require the option, turn the option off, and have the result be that the first message with an encrypted length is the first one after the NEWKEYS message. Alternately, we could simply allow a "delayed-on" or "delayed-off" whose effect takes place with the first message after the next NEWKEYS, rather than immediately. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 19:16:23 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 022E73A6D20 for ; Thu, 9 Apr 2009 19:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.733, 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 wbmyN5bq-Ngt for ; Thu, 9 Apr 2009 19:16:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E7CFC3A69F6 for ; Thu, 9 Apr 2009 19:16:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A1EB63B283; Fri, 10 Apr 2009 02:17:26 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 4CA0D63B2AA for ; Fri, 10 Apr 2009 02:17:25 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A2HM6L004239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 22:17:22 -0400 (EDT) Date: Thu, 09 Apr 2009 22:17:22 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: <200904091437.KAA28225@Sparkle.Rodents-Montreal.ORG> References: <200904091437.KAA28225@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 10:33:52 AM -0400 der Mouse wrote: >>> I think any option that changes the binary packet format would need >>> to be included in the kex hash to prevent downgrade/upgrade attacks. >>> This is somewhat annoying implementation-wise if it is a separate >>> packet. > >> Is there any way of doing some sort of pre-auth to prevent tampering >> with the options packets? > > You could simply decree that options packets for the option in question > are not acceptable if sent before the first kex completes. (I'd > hesitate to do that for all options packets, but it may be necessary.) The problem with doing it for all option packets is that doing so precludes negotiating cleartext-packet-lengths before the first kex completes, which is necessary if the first kex selects an encryption algorithm requiring cleartext packet lengths. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 19:26: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 EC41728C12C for ; Thu, 9 Apr 2009 19:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.88 X-Spam-Level: X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.719, 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 TNBraa0klKTl for ; Thu, 9 Apr 2009 19:26:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C8DF23A6452 for ; Thu, 9 Apr 2009 19:26:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 04BE663B29D; Fri, 10 Apr 2009 02:27:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 8851363B2AF for ; Fri, 10 Apr 2009 02:27:41 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A2Rc0w004435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 22:27:38 -0400 (EDT) Date: Thu, 09 Apr 2009 22:27:38 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: <200904091558.LAA28713@Sparkle.Rodents-Montreal.ORG> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> <200904090008.UAA23669@Sparkle.Rodents-Montreal.ORG> <98842F916ED550B63C6C1860@atlantis.pc.cs.cmu.edu> <200904091558.LAA28713@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 11:38:39 AM -0400 der Mouse wrote: > Putting it that way reveals, perhaps, part of the problem. There is no > particular reason why the code that reads data from the wire data > stream (usually but not necessarily TCP) has to know where packet > boundaries are. As long as every packet boundary falls at a place such > that the data->encryption->decryption->data pipeline can deliver the > whole packet without needing more input data (which is the point of > padding to a multiple of the blocksize), the protocol can work. This > does mean that implementations which expect to issue wire data stream > reads for exactly the right amount of data early in packet processing > will be constrained in what encryption algorithms they implement, > though as far as I know no algorithms which would make that a practical > constraint are implemented for ssh (and my suggestion above is not one, > since the encryption algorithm layer can provide the wire length early). Hm. Yes, that's true. And it's even a good idea; the recent problems with encrypted packet lengths would be much less serious if reading and decrypting the TCP stream were decoupled from processing the SSH packet stream. Of course, that introduces some interesting buffering requirements to allow a NEWKEYS message to result in a pipeline flush, but it shouldn't be unreasonable. Hrm, except the MAC is unencrypted, so they can't be completely decoupled. That doesn't make it unworkable, though, provided one defines an appropriate interface to the encryption code. > Yes, there are doubtless implementations which assume that encrypted > and cleartext are the same size. They will need internal rework if > they are to implement any of this stuff, but I don't see that as a > reason to twist the design uncomfortably; it just means implementing it > for them, if done at all, will be more work. Yes, that's probably true. Interestingly, if we can agree that using plaintext lengths does _not_ require changing the way the size of the padding field is determined, then it becomes possible for an encryption algorithm to use plaintext lengths without changing the base protocol, the modularity argument goes away, and the need to enable negotiation of cleartext lengths independently of the encryption algorithm becomes less pressing (but possibly still desirable). It does mean that if we do both, we need to point out that implementations which support both such an algorithm and algorithm-independnet cleartext lengths not inadvertently send both the length and the _next_ 4 bytes in plaintext. :-) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 19:57:20 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 9FD9B3A69DC for ; Thu, 9 Apr 2009 19:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.223, 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 Q65mRvrZewQs for ; Thu, 9 Apr 2009 19:57:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D45F53A6D23 for ; Thu, 9 Apr 2009 19:57:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 22B3963B2B2; Fri, 10 Apr 2009 02:58:21 +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 CF49363B2BA for ; Fri, 10 Apr 2009 02:58:17 +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 n39GpuOC000377 for ; Thu, 9 Apr 2009 16:51:56 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 n39GppIO065453 for ; Thu, 9 Apr 2009 10:51:51 -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 n39G4uW2007329; Thu, 9 Apr 2009 11:04:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39G4mGH007328; Thu, 9 Apr 2009 11:04:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 9 Apr 2009 11:04:47 -0500 From: Nicolas Williams To: Damien Miller Cc: Peter Gutmann , jhutz@cmu.edu, clonvick@cisco.com, ietf-ssh@NetBSD.org, jasolin@orion.ncsc.mil, kivinen@iki.fi, kmigoe@nsa.gov, Pasi.Eronen@nokia.com, sommerfeld@Sun.COM, tim.polk@nist.gov, ylo@ssh.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090409160447.GA1500@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 04:33:44PM +1000, Damien Miller wrote: > On Thu, 9 Apr 2009, Peter Gutmann wrote: > > > Nicolas Williams writes: > > > > >[So far the only extensibility mechanisms that we have at that point in the > > >protocol are: new protocol version number (not going to happen) and magic > > >algorithm names (which have been used successfully).] > > > > ... and the completely unused 32-bit flags field in the first message, which I > > mentioned previously :-). > > I think it would be much safer to define new cipher names for this. I agree. That or magic alg names (e.g., "all-ciphers-have-plaintext-packet-length"). The reserved uint32 will be, at the very least, difficult to use. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 21:39: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 308483A69A4 for ; Thu, 9 Apr 2009 21:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.222, 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 WqpVLCFmNvjj for ; Thu, 9 Apr 2009 21:39:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2AA653A698B for ; Thu, 9 Apr 2009 21:39:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1602363B175; Fri, 10 Apr 2009 04:40:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 5755063B119 for ; Fri, 10 Apr 2009 04:40:30 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3A4eRWo028771 for ; Fri, 10 Apr 2009 04:40:27 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 n3A4eR1b032487 for ; Thu, 9 Apr 2009 22:40:27 -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 n3A4V6Jh007958; Thu, 9 Apr 2009 23:31:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3A4V6To007957; Thu, 9 Apr 2009 23:31:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 9 Apr 2009 23:31:05 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090410043105.GR1500@Sun.COM> References: <49DE51A1.6020602@vandyke.com> <200904100049.UAA02426@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904100049.UAA02426@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 08:47:08PM -0400, der Mouse wrote: > > How about a quick straw poll, since we've probably got a good number > > of implemeters here. If your implementation sees a non-zero value in > > the RFU field, will it: > > Ignore it. (I've been considering warning and disconnecting as other > possible reactions, but haven't seen any compelling reason to prefer > one over another. Perhaps it's time for another configuration > parameter - a little difficult to test, though.) Given that key exchange is not retriable I think the best thing to do is to ignore this field and always place a zero there until we define its meaning. That will allow us to use it to negotiate new features when both the client and server advertise them (non-zero values). From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 21:40:49 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 21BCD3A6A4D for ; Thu, 9 Apr 2009 21:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.221, 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 n1qXExcv+X3J for ; Thu, 9 Apr 2009 21:40:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D0FC33A684A for ; Thu, 9 Apr 2009 21:40:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0507763B119; Fri, 10 Apr 2009 04:41:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 4BAB663B110 for ; Fri, 10 Apr 2009 04:41:36 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3A4fZ96022712 for ; Fri, 10 Apr 2009 04:41:35 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 n3A4fZjU032787 for ; Thu, 9 Apr 2009 22:41:35 -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 n3A4HBGO007938; Thu, 9 Apr 2009 23:17:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3A4H85F007937; Thu, 9 Apr 2009 23:17:08 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 9 Apr 2009 23:17:08 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090410041707.GO1500@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 09, 2009 at 11:42:55AM -0400, Jeffrey Hutzelman wrote: > No, I think the right thing is for the SSH_MSG_OPTION message itself to be > permitted at any time, and leave it to the definitions of individual > options to specify when an option may be negotiated and when the results of > that negotiation take effect. > > [...] > > With regard to the negotiation itself, I think it might be cleaner to have > three separate messages: Surely you jest. Why get so complicated when the much simpler negotiation through alg names will do? What value is there in this complication? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 21:58: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 531583A6D2B for ; Thu, 9 Apr 2009 21:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 j7nJdrzVSMcI for ; Thu, 9 Apr 2009 21:58:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2E8083A69A4 for ; Thu, 9 Apr 2009 21:58:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E6C363B123; Fri, 10 Apr 2009 04:59:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 1351663B11F for ; Fri, 10 Apr 2009 04:59:07 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A4wujH008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 00:58:56 -0400 (EDT) Date: Fri, 10 Apr 2009 00:58:56 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> In-Reply-To: <20090410041707.GO1500@Sun.COM> References: <20090410041707.GO1500@Sun.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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 11:17:08 PM -0500 Nicolas Williams wrote: > On Thu, Apr 09, 2009 at 11:42:55AM -0400, Jeffrey Hutzelman wrote: >> No, I think the right thing is for the SSH_MSG_OPTION message itself to >> be permitted at any time, and leave it to the definitions of individual >> options to specify when an option may be negotiated and when the results >> of that negotiation take effect. >> >> [...] >> >> With regard to the negotiation itself, I think it might be cleaner to >> have three separate messages: > > Surely you jest. Why get so complicated when the much simpler > negotiation through alg names will do? What value is there in this > complication? - generality - allowing the feature to be negotiated for any algorithm, not just a particular gcm algorithm, without a cross product explosion -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 22:07:06 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 362C53A6BF4 for ; Thu, 9 Apr 2009 22:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, 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 dCAxTJr1drb6 for ; Thu, 9 Apr 2009 22:07:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2BE483A6A63 for ; Thu, 9 Apr 2009 22:07:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 745A663B12C; Fri, 10 Apr 2009 05:08:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 EA7CE63B110 for ; Fri, 10 Apr 2009 05:08:05 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A57FlF008326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 01:07:15 -0400 (EDT) Date: Fri, 10 Apr 2009 01:07:15 -0400 From: Jeffrey Hutzelman To: "Igoe, Kevin M." , Damien Miller , Tim Polk cc: ietf-ssh@NetBSD.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Jerome A. Solinas" , Pasi.Eronen@nokia.com, jhutz@cmu.edu Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <414CF19E6018106E70A3867A@atlantis.pc.cs.cmu.edu> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB034935@MSIS-GH1-UEA06.corp.nsa.gov> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB034935@MSIS-GH1-UEA06.corp.nsa.gov> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 09, 2009 08:36:24 AM -0400 "Igoe, Kevin M." wrote: > Damien Miller writes: > >> 5.1/5.2 - The suggested algorithm names are structurally different to >> the other algorithm identifiers used in SSH. In particular, I don't see >> any need for the "-ssh" to appear in the algorithm name as the cipher >> has not been modified in any substantial way. Why not just "aes128-gcm" >> or "aes128-gcm-aead" if you wanted to be particularly verbose? > > AEAD has its own convention for naming algorithms. The names selected > are more in keeping with the AEAD conventions. I'm not terribly fond of > theses names and would be willing to modify them as needed, but I'd like > to keep an "ssh" tag in the name so that when one looks at the namespace > of all AEAD algorithms, it is clear that these algorithms are intended > for use in secsh. I don't understand. There is nothing "ssh" about the algorithm; it's just AES128 in GCM mode, no? Any "how to use this in SSH bits" are part of the SSH spec but not part of the algorithm. I'm not sure what value there is in a "namespace of all AEAD algorithms"; is there some registry you are concerned about? Why would an ssh encryption algorithm name ever appear in a context other than ssh algorithm negotiation? Why would you expect the names of, say, SSH encryption algorithms, TLS cipher suites, and Kerberos enctypes not to overlap? In the context of the namespace in which these values are actually defined, which is that of SSH encryption algorithm names, the "-ssh" adds no value. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 22:25: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 8C9A33A6885 for ; Thu, 9 Apr 2009 22:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.679, 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 qz5i5+WlvHEm for ; Thu, 9 Apr 2009 22:25:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BB6733A6D2B for ; Thu, 9 Apr 2009 22:25:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 13CC263B14A; Fri, 10 Apr 2009 05:26:53 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 5AA8D63B12B for ; Fri, 10 Apr 2009 05:26:50 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3A5Qgl1008499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 01:26:44 -0400 (EDT) Date: Fri, 10 Apr 2009 01:26:42 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <39B0720C9A977A8831C2FACB@atlantis.pc.cs.cmu.edu> In-Reply-To: <20090410050331.GQ1667@Sun.COM> References: <20090410041707.GO1500@Sun.COM> <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> <20090410050235.GT1500@Sun.COM> <20090410050331.GQ1667@Sun.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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Friday, April 10, 2009 12:03:31 AM -0500 Nicolas Williams wrote: > On Fri, Apr 10, 2009 at 12:02:35AM -0500, Nicolas Williams wrote: >> On Fri, Apr 10, 2009 at 12:58:56AM -0400, Jeffrey Hutzelman wrote: >> > - generality >> > - allowing the feature to be negotiated for any algorithm, not just >> > a particular gcm algorithm, without a cross product explosion >> >> I'd rather have a magic alg name that does this. It's less code, a lot >> less code. We don't need no stinking generality here :) given that we >> weren't given it to begin with :) >> >> BTW, I would love to use the reserved field of KEXINIT to negotiate >> retriable key exchagne (a big deal for gss keyex). > > Sent to soon. I meant to add that your scheme isn't general enough to > give us retriable kexinit... Why not? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 22:26: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 CD2823A6A96 for ; Thu, 9 Apr 2009 22:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.220, 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 r8cc9TEQ5-jh for ; Thu, 9 Apr 2009 22:26:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B87443A687E for ; Thu, 9 Apr 2009 22:26:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7764263B149; Fri, 10 Apr 2009 05:27:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id A440E63B136 for ; Fri, 10 Apr 2009 05:26:59 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3A5QvXZ029859 for ; Fri, 10 Apr 2009 05:26: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 n3A5QvHb060595 for ; Thu, 9 Apr 2009 23:26: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 n3A52aDR007977; Fri, 10 Apr 2009 00:02:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3A52Zgm007976; Fri, 10 Apr 2009 00:02:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 10 Apr 2009 00:02:35 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090410050235.GT1500@Sun.COM> References: <20090410041707.GO1500@Sun.COM> <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Apr 10, 2009 at 12:58:56AM -0400, Jeffrey Hutzelman wrote: > --On Thursday, April 09, 2009 11:17:08 PM -0500 Nicolas Williams > wrote: > > >On Thu, Apr 09, 2009 at 11:42:55AM -0400, Jeffrey Hutzelman wrote: > >>No, I think the right thing is for the SSH_MSG_OPTION message itself to > >>be permitted at any time, and leave it to the definitions of individual > >>options to specify when an option may be negotiated and when the results > >>of that negotiation take effect. > >> > >>[...] > >> > >>With regard to the negotiation itself, I think it might be cleaner to > >>have three separate messages: > > > >Surely you jest. Why get so complicated when the much simpler > >negotiation through alg names will do? What value is there in this > >complication? > > - generality > - allowing the feature to be negotiated for any algorithm, not just > a particular gcm algorithm, without a cross product explosion I'd rather have a magic alg name that does this. It's less code, a lot less code. We don't need no stinking generality here :) given that we weren't given it to begin with :) BTW, I would love to use the reserved field of KEXINIT to negotiate retriable key exchagne (a big deal for gss keyex). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 22:54: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 431123A6D49 for ; Thu, 9 Apr 2009 22:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.149 X-Spam-Level: X-Spam-Status: No, score=-9.149 tagged_above=-999 required=5 tests=[AWL=0.839, 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 4QqxZivL2Iyy for ; Thu, 9 Apr 2009 22:54:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6A1613A6D47 for ; Thu, 9 Apr 2009 22:54:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9A70C63B115; Fri, 10 Apr 2009 05:55:56 +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 ABBF963B110 for ; Fri, 10 Apr 2009 05:55:54 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id BAA11295; Fri, 10 Apr 2009 01:55:53 -0400 (EDT) From: der Mouse Message-Id: <200904100555.BAA11295@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: Fri, 10 Apr 2009 01:48:01 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090410043105.GR1500@Sun.COM> References: <49DE51A1.6020602@vandyke.com> <200904100049.UAA02426@Sparkle.Rodents-Montreal.ORG> <20090410043105.GR1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Given that key exchange is not retriable I think the best thing to do > is to ignore [the currently-0 last field of SSH_MSG_KEXNIIT] and > always place a zero there until we define its meaning. That will > allow us to use it to negotiate new features when both the client and > server advertise them (non-zero values). Not without breaking interoperability with existing implementations that check that the field is zero. Or do you maintain that there are no such? Or that interoperability with them doesn't matter? I find the latter severely busted and the former unlikely, especially since the spec does not even suggest, much less specify, behaviour for an implementation which encounters a value for that field that it doesn't understand. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 23:10: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 4E3C63A6938 for ; Thu, 9 Apr 2009 23:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.189 X-Spam-Level: X-Spam-Status: No, score=-9.189 tagged_above=-999 required=5 tests=[AWL=0.799, 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 r6Y+q4i2HnOn for ; Thu, 9 Apr 2009 23:10:17 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6A5F83A6D34 for ; Thu, 9 Apr 2009 23:10:17 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D172E63B140; Fri, 10 Apr 2009 06:11: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 DB2F163B109 for ; Fri, 10 Apr 2009 06:11:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id CAA11368; Fri, 10 Apr 2009 02:11:16 -0400 (EDT) From: der Mouse Message-Id: <200904100611.CAA11368@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: Fri, 10 Apr 2009 01:57:37 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090410050235.GT1500@Sun.COM> References: <20090410041707.GO1500@Sun.COM> <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> <20090410050235.GT1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> Surely you jest. Why get so complicated when the much simpler >>> negotiation through alg names will do? What value is there in this >>> complication? >> - generality >> - allowing the feature to be negotiated for any algorithm, not just >> a particular gcm algorithm, without a cross product explosion > I'd rather have a magic alg name that does this. It's less code, a > lot less code. That's not the only metric that matters. > We don't need no stinking generality here :) given that we weren't > given it to begin with :) That's why we're trying to design a clean mechanism that provides it, rather than throwing in a kludge for this case, another kludge for next case, and pretty soon you're shoehorning protocol version numbers into the authentication username string or some such horror. > BTW, I would love to use the reserved field of KEXINIT to negotiate > retriable key exchagne (a big deal for gss keyex). Why? Why not just have the gss kex define its kex-method-specific messages so as to permit multiple back-and-forths, retrying as much as necessary to find something suitable? Actually, perhaps the best way to answer that would be to sketch the semantics for the retryable-kex bit you'd like to define; then I could probably see what the issue is (or suggest a way that doesn't break interoperability that badly, using existing facilities). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 23:48: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 09EDD3A6BAD for ; Thu, 9 Apr 2009 23:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.219, 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 TaO32nY9WDG8 for ; Thu, 9 Apr 2009 23:48:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2786D3A6B1E for ; Thu, 9 Apr 2009 23:48:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2008563B110; Fri, 10 Apr 2009 06:49:10 +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 0D03563B109 for ; Fri, 10 Apr 2009 06:49:07 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3A5Rrc9001058 for ; Fri, 10 Apr 2009 05:27:53 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 n3A5RroX060837 for ; Thu, 9 Apr 2009 23:27:53 -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 n3A53W1L007983; Fri, 10 Apr 2009 00:03:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3A53WOv007982; Fri, 10 Apr 2009 00:03:32 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 10 Apr 2009 00:03:31 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Peter Gutmann , ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090410050331.GQ1667@Sun.COM> References: <20090410041707.GO1500@Sun.COM> <936C9A9E04B38C63A1A75FAD@atlantis.pc.cs.cmu.edu> <20090410050235.GT1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090410050235.GT1500@Sun.COM> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Fri, Apr 10, 2009 at 12:02:35AM -0500, Nicolas Williams wrote: > On Fri, Apr 10, 2009 at 12:58:56AM -0400, Jeffrey Hutzelman wrote: > > - generality > > - allowing the feature to be negotiated for any algorithm, not just > > a particular gcm algorithm, without a cross product explosion > > I'd rather have a magic alg name that does this. It's less code, a lot > less code. We don't need no stinking generality here :) given that we > weren't given it to begin with :) > > BTW, I would love to use the reserved field of KEXINIT to negotiate > retriable key exchagne (a big deal for gss keyex). Sent to soon. I meant to add that your scheme isn't general enough to give us retriable kexinit... From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 9 23:48:21 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 5B0913A6D3D for ; Thu, 9 Apr 2009 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.226 X-Spam-Level: X-Spam-Status: No, score=-9.226 tagged_above=-999 required=5 tests=[AWL=0.762, 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 jkQ+bFCyH0QW for ; Thu, 9 Apr 2009 23:48:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 224163A6D0F for ; Thu, 9 Apr 2009 23:48:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1BDA563B137; Fri, 10 Apr 2009 06:49:23 +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 395C663B131 for ; Fri, 10 Apr 2009 06:49:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id CAA11642; Fri, 10 Apr 2009 02:49:15 -0400 (EDT) From: der Mouse Message-Id: <200904100649.CAA11642@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: Fri, 10 Apr 2009 02:16:20 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <7E7111ED15B11C34073BFD9E@minbar.fac.cs.cmu.edu> <200904082035.QAA22321@Sparkle.Rodents-Montreal.ORG> <200904090008.UAA23669@Sparkle.Rodents-Montreal.ORG> <98842F916ED550B63C6C1860@atlantis.pc.cs.cmu.edu> <200904091558.LAA28713@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> [...decoupling wire data reads from decryption...] > Of course, that introduces some interesting buffering requirements to > allow a NEWKEYS message to result in a pipeline flush, but it > shouldn't be unreasonable. Or, rather, a pipeline back-up-and-reprocess. :-/ > Hrm, except the MAC is unencrypted, so they can't be completely > decoupled. That's true. Hm, I wonder how I dealt with that in moussh; when I read the packet reading code for an upthread message, they sure looked pretty decoupled. *rummage* *read* Ah. My downcall to the cryptosystem implementation has semantics that amount to "here's a buffer of input ciphertext, a ciphertext amount, a buffer for cleartext, and a maximum amount of cleartext I want; if I'm providing excess ciphertext, don't consume more than is necessary to provide all the cleartext I'm asking for", addressing both the MAC issue and the NEWKEYS issue. > Interestingly, if we can agree that using plaintext lengths does > _not_ require changing the way the size of the padding field is > determined, then it becomes possible for an encryption algorithm to > use plaintext lengths without changing the base protocol, the > modularity argument goes away, and the need to enable negotiation of > cleartext lengths independently of the encryption algorithm becomes > less pressing (but possibly still desirable). Agreed on all counts. > It does mean that if we do both, we need to point out that > implementations which support both such an algorithm and > algorithm-independnet cleartext lengths not inadvertently send both > the length and the _next_ 4 bytes in plaintext. :-) Right - they may well end up sending the length (in the clear) twice if they get careless, but I don't see any need to make it impossible to negotiate wasteful combinations of settings. /~\ 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 Apr 13 19:35:07 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 8BD593A6CCA for ; Mon, 13 Apr 2009 19:35:07 -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 TiDBh5dLjTWQ for ; Mon, 13 Apr 2009 19:35:06 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C073D3A689A for ; Mon, 13 Apr 2009 19:35:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8650063B2DD; Tue, 14 Apr 2009 02:36:06 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 7DC9A63B22A for ; Tue, 14 Apr 2009 02:35:55 +0000 (UTC) Received: from [131.181.102.5] ([131.181.102.5]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n3E1WqE0003457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 Apr 2009 21:32:57 -0400 (EDT) Message-Id: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> From: Douglas Stebila To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: New version: draft-green-secsh-ecc-06 Date: Tue, 14 Apr 2009 11:32:47 +1000 X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Mon, 13 Apr 2009 21:32:57 -0400 (EDT) X-Miltered: at psyche with ID 49E3E7C4.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on localhost X-Virus-Status: Clean X-UUID: 8507ec0c-ff34-4ee8-a2f8-cc408089d47c Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list A new version of the draft for elliptic curve cryptography in SSH has been posted. http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-06.txt The main substantive revision is that ecdsa-sha2 is now using a family of identifiers (as ecdh-sha2-* does) to specify the curve at the algorithm negotiation stage. Douglas From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 21:06:05 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 1F1013A6A9F for ; Mon, 13 Apr 2009 21:06:05 -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 X-Q8b6MaxF4Y for ; Mon, 13 Apr 2009 21:06:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2DF9E3A6A6F for ; Mon, 13 Apr 2009 21:06:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A2F0E63B117; Tue, 14 Apr 2009 04:07:00 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 3E69563B19B for ; Tue, 14 Apr 2009 04:06:57 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id CB541C4BB0; Tue, 14 Apr 2009 14:06:54 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id E179FC4B9F; Tue, 14 Apr 2009 14:06:48 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 64A26A4F54; Tue, 14 Apr 2009 14:06:48 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 628B5A4F51; Tue, 14 Apr 2009 14:06:48 +1000 (EST) Date: Tue, 14 Apr 2009 14:06:48 +1000 (EST) From: Damien Miller To: Douglas Stebila cc: ietf-ssh@netbsd.org Subject: Re: New version: draft-green-secsh-ecc-06 In-Reply-To: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> Message-ID: References: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Tue, 14 Apr 2009, Douglas Stebila wrote: > A new version of the draft for elliptic curve cryptography in SSH has been > posted. > > http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-06.txt > > The main substantive revision is that ecdsa-sha2 is now using a family of > identifiers (as ecdh-sha2-* does) to specify the curve at the algorithm > negotiation stage. I have to say that I really dislike the Base64(MD5(DER(OID))) encoding of curve names into the kex method names. Why not just use the SEC names? Actually, why bake the names into the kex names at all? (as opposed to sending a curve spec as a parameter). Do the many ECC patent apply to the methods described in this draft? It seems to lack any section on IPR. The "Security Considerations" section talks about the possible need to replace SHA2 with other algorithms, but the name "sha2" is baked into the kex method name. Should the hash algorithm be a parameter too? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 21:42:25 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 5EE2F3A6A9F for ; Mon, 13 Apr 2009 21:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s-rgyG1iKNP for ; Mon, 13 Apr 2009 21:42:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2CEF53A68FB for ; Mon, 13 Apr 2009 21:42:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5D44863B145; Tue, 14 Apr 2009 04:43:22 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 9E1A763B117 for ; Tue, 14 Apr 2009 04:43:19 +0000 (UTC) Received: from [131.181.102.5] ([131.181.102.5]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n3E4h6Px008714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Apr 2009 00:43:12 -0400 (EDT) Cc: ietf-ssh@netbsd.org Message-Id: From: Douglas Stebila To: Damien Miller In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: New version: draft-green-secsh-ecc-06 Date: Tue, 14 Apr 2009 14:43:01 +1000 References: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Tue, 14 Apr 2009 00:43:13 -0400 (EDT) X-Miltered: at mailchk-m01 with ID 49E4145A.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on localhost X-Virus-Status: Clean X-UUID: abe570d8-8f5d-429d-aa15-28e623be9fef Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On 2009-Apr-14, at 2:06 PM, Damien Miller wrote: > I have to say that I really dislike the Base64(MD5(DER(OID))) encoding > of curve names into the kex method names. Why not just use the SEC > names? Not all curves have SEC names. There exist standardized curves that have OIDs but not SEC names. The most relevant curves in my mind are the NIST Suite B curves, which are a subset of the NIST curves, which are a subset of the SEC curves, which are a subset of all curves with OIDs, which are a subset of all curves. One could draw the line anywhere, and currently the line is drawn at OIDs. I would need more feedback from implementers as to whether only SEC curves suffice. I recognize that for many implementers the driving force right now is NSA Suite B compliance, which requires only secp256r1 or secp384r1. As for the Base64(MD5(DER(OID))) encoding: I was told that not all OIDs are guaranteed to be sufficiently short to keep the overall method name down to no more than 64 characters as required by RFC 4251 Section 6. This mechanism guarantees sufficiently short method names which are extensible and (almost certainly) unique. > Actually, why bake the names into the kex names at all? (as opposed to > sending a curve spec as a parameter). This would require a second round of negotiation, which could fail. Suppose that two implementations agreed to use ecdh-sha2 and then in the subsequent curve negotiation discovered that they had no common set of curves (this may be possible as REQUIRED curves can still be disabled by local security policy). I don't believe SSH has a mechanism for dealing with a failed kex method by moving on to the next method in the list of mutually supported kex methods, but I could be mistaken about that. (For comparison, when ECC was added to TLS a similar problem arose and they used extensions in the client_hello and server_hello messages to transport the list of supported curves. I don't know any way other way around this problem, but if you know of one I'd be happy to consider it. > Do the many ECC patent apply to the methods described in this draft? > It > seems to lack any section on IPR. Other IETF documents involving ECC, such as RFC 3278 (ECC in CMS) and RFC 4492 (ECC in TLS) do not include a discussion speculating on how the documents are affected by ECC patents. I am not a lawyer and do not feel qualified to include any speculation of my own in the document. > The "Security Considerations" section talks about the possible need to > replace SHA2 with other algorithms, but the name "sha2" is baked into > the kex method name. Should the hash algorithm be a parameter too? That's an option, although one that I don't think is worth pursuing at this point. The SHA-3 competition is a long way from being done, so SHA-2 is the gold standard right now. If there's a desire to see SHA-3 adopted in SSH, it would not be hard to create a short RFC indicating that SHA-3 could be substituted fro SHA-2, and this draft, while not explicitly saying how to do it, is very suggestive. Douglas From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 22:24: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 0F8383A6D90 for ; Mon, 13 Apr 2009 22:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 xidGDIERNoLv for ; Mon, 13 Apr 2009 22:24:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 35F7A3A6D6E for ; Mon, 13 Apr 2009 22:24:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 76E8E63B196; Tue, 14 Apr 2009 05:25:50 +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 3EE6A63B1AE for ; Tue, 14 Apr 2009 05:25:47 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5AB0A482A42; Tue, 14 Apr 2009 17:25:46 +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 l+AU7v1A6K1M; Tue, 14 Apr 2009 17:25:46 +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 DAD24482A3A; Tue, 14 Apr 2009 17:25:41 +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 34F5A1DE4001; Tue, 14 Apr 2009 17:25:37 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Ltb9M-0006eW-WE; Tue, 14 Apr 2009 17:25:37 +1200 From: Peter Gutmann To: djm@mindrot.org, douglas@stebila.ca Subject: Re: New version: draft-green-secsh-ecc-06 Cc: ietf-ssh@netbsd.org In-Reply-To: Message-Id: Date: Tue, 14 Apr 2009 17:25:36 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller writes: >I have to say that I really dislike the Base64(MD5(DER(OID))) encoding of >curve names into the kex method names. Why not just use the SEC names? Oh, so it wasn't just me :-). My reaction to seeing this was "did someone lose a bet or something...". >Actually, why bake the names into the kex names at all? (as opposed to >sending a curve spec as a parameter). This is another case where SSH really needs an extension mechanism like TLS. In TLS the curve parameters and point formats are negotiated via extensions. Having said that, in practice everyone (well, among TLS implementors) has settled on a small number of popular curves and that's it (which is quite convenient, you don't even have to worry about extensions, just go with P256 and everything'll support it). I'd define a few fixed names for the well-known curves that everyone ends up using (the NIST ones, basically) and leave the strange stuff to the usual name@vendor-name mechanism, which is exactly what it was meant for. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 22:52: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 863193A67F8 for ; Mon, 13 Apr 2009 22:52:29 -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 VlQbQvbveXEU for ; Mon, 13 Apr 2009 22:52:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 48CB63A67D1 for ; Mon, 13 Apr 2009 22:52:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D091A63B117; Tue, 14 Apr 2009 05:53:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 33B0D63B10E for ; Tue, 14 Apr 2009 05:53:31 +0000 (UTC) Received: from [131.181.102.5] ([131.181.102.5]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n3E5rHsH001982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Apr 2009 01:53:22 -0400 (EDT) Cc: djm@mindrot.org, ietf-ssh@netbsd.org Message-Id: <441ACB35-9662-48E8-A2DD-CABE45201343@stebila.ca> From: Douglas Stebila To: Peter Gutmann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: New version: draft-green-secsh-ecc-06 Date: Tue, 14 Apr 2009 15:53:12 +1000 References: X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Tue, 14 Apr 2009 01:53:25 -0400 (EDT) X-Miltered: at minos with ID 49E424CD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on localhost X-Virus-Status: Clean X-UUID: df527df7-ae95-4838-95ca-18ef635fcb2a Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> I have to say that I really dislike the Base64(MD5(DER(OID))) >> encoding of >> curve names into the kex method names. Why not just use the SEC >> names? > > Oh, so it wasn't just me :-). My reaction to seeing this was "did > someone > lose a bet or something...". As I mentioned, this was a change that my IETF document shepherd asked me to make in going from -02 to -03. I agree it's ugly. >> Actually, why bake the names into the kex names at all? (as opposed >> to >> sending a curve spec as a parameter). > > This is another case where SSH really needs an extension mechanism > like TLS. > In TLS the curve parameters and point formats are negotiated via > extensions. I'm afraid that's outside the scope of my lowly draft. :) > Having said that, in practice everyone (well, among TLS > implementors) has > settled on a small number of popular curves and that's it (which is > quite > convenient, you don't even have to worry about extensions, just go > with P256 > and everything'll support it). I'd define a few fixed names for the > well-known curves that everyone ends up using (the NIST ones, > basically) and > leave the strange stuff to the usual name@vendor-name mechanism, > which is > exactly what it was meant for. If the consensus on this mailing list is that using a few fixed names is fine, then I am willing to make that change. My preference would be the following: Method names are ecdh-sha2-[identifier] and ecdsa-sha2-[identifier], where [identifier] is nistp256 -- REQUIRED (Suite B) nistp384 -- REQUIRED (Suite B) Base64(MD5(DER(OID))) -- OPTIONAL with the additional proviso that, if the curve in question is in fact nistp256 (== secp256r1) or nistp384 (== secp384r1), then implementations MUST use the nistp256/nistp384 naming convention and MUST NOT use the Base64(MD5(DER(OID))) naming convention. The rationale for this compromise is as follows. It seems as if we expect the vast majority of implementations to be aiming for Suite B which is nistp256 and nistp384. Those implementations need never worry about the ugly names. For implementations that want to go beyond Suite B, they can use the ugly (but universal and extensible) names. Points for debate: 1) Should the list of named curves be longer, for example, including all the NIST curves or all the SEC curves? 2) Should the named curves be named by their NIST name or their SEC name? (nistp256 versus secp256r1) 3) Should we entirely remove the Base64(MD5(DER(OID))) optional encoding and entirely leave it to name@vendor-name? My opinion is no: Although name@vendor-name is the common mechanism for naming additional SSH mechanisms, elliptic curves in other standards are often named with OIDs which are universal. Regards, Douglas From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 23:28: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 C50C928C14D for ; Mon, 13 Apr 2009 23:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.575 X-Spam-Level: X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, 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 7h1jXeGyI7K0 for ; Mon, 13 Apr 2009 23:28:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A069128C12C for ; Mon, 13 Apr 2009 23:28:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 908EB63B159; Tue, 14 Apr 2009 06:29:03 +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 9A54A63B142 for ; Tue, 14 Apr 2009 06:28:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 5DBE99F0C9; Tue, 14 Apr 2009 18:28:58 +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 pQM83KPHrQFq; Tue, 14 Apr 2009 18:28:58 +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 EF89D9F09D; Tue, 14 Apr 2009 18:28:53 +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 6B6F21DE4001; Tue, 14 Apr 2009 18:28:53 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Ltc8b-0001Xq-9u; Tue, 14 Apr 2009 18:28:53 +1200 From: Peter Gutmann To: douglas@stebila.ca, pgut001@cs.auckland.ac.nz Subject: Re: New version: draft-green-secsh-ecc-06 Cc: djm@mindrot.org, ietf-ssh@netbsd.org In-Reply-To: <441ACB35-9662-48E8-A2DD-CABE45201343@stebila.ca> Message-Id: Date: Tue, 14 Apr 2009 18:28:53 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Douglas Stebila writes: >My preference would be the following: > >[...] That sounds sensible. >1) Should the list of named curves be longer, for example, including all the >NIST curves or all the SEC curves? This could be really hard to answer because there isn't enough operational experience in using these. I know from TLS that some people seem to be implementing every curve they can think of, but also that these are a lot of our-curves-go-to-11 implementations done more to show off the capabilities for interop purposes rather than everyday use (whoever ships with the most curves wins). If you look at the more mainstream implementations they're mostly just Suite-B and that's it, for example Vista (via MSIE/IIS/whatever) just does P256, 384, and 521 and that's it. This is why your suggestion to have the two Suite-B's (and I'd add 521 to that) as the mandatory-to-support standard is a good one, you can pretty much assume that everyone will do that anyway. >2) Should the named curves be named by their NIST name or their SEC name? >(nistp256 versus secp256r1) I'd go for NIST for the Suite-B's and SECG for the rest, because they've named a lot more than NIST has. This also means that you could define Suite-B's as mandatory, refer to the SECG names (via "as defined in 'SEC 2:2000' or any later version") for the remaiming names without explicitly having to catalogue them all, and then leave the hash as anything-that's-left. Having said that though I'm still a bit nervous about using the OIDs, there are all sorts of other odd things you can do with those that could cause problems, for example there's the "use this with a hash algorithm that's the largest possible that can be used with the curve without truncation" OID and the "dance along the wharf slapping people with a dead fish" OID and ... . Since you can have multiple OIDs for a curve and anything that defines an OID will also define a curve name, it'd be much easier to just use the name directly since you're not getting much from the OID except complexity. If you really want to be safe, use 'name@source', e.g. curve1@standardsgroupname, although even then it seems that groups are being careful to choose unique names. For example all the SECG names being 'sec' to distinguish them from other names. BTW the TLS ECC RFC has a table at the end mapping X9.62 <-> NIST <-> SECG names for people who need this. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 13 23:39:07 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 AC01C3A68AA for ; Mon, 13 Apr 2009 23:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.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 01TGmworbO6S for ; Mon, 13 Apr 2009 23:39:06 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 551833A685A for ; Mon, 13 Apr 2009 23:39:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5915563B1AE; Tue, 14 Apr 2009 06:40:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from smtp7.xenetic.net (smtp7.xenetic.net [80.88.176.189]) (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 583C363B15A for ; Tue, 14 Apr 2009 06:40:07 +0000 (UTC) Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp7.xenetic.net (8.14.3/8.14.3) with ESMTP id n3E6e3Vq019264 for ; Tue, 14 Apr 2009 09:40:03 +0300 Received: from [10.1.254.253] ([10.1.254.253]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 09:40:03 +0300 Message-ID: <49E42FC2.5090805@ssh.com> Date: Tue, 14 Apr 2009 09:40:02 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Re: New version: draft-green-secsh-ecc-06 References: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2009 06:40:03.0520 (UTC) FILETIME=[D769FC00:01C9BCCB] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4,1.2.40,4.0.166 definitions=2009-04-14_03:2009-04-13,2009-04-14,2009-04-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904130211 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller wrote: > On Tue, 14 Apr 2009, Douglas Stebila wrote: > >> A new version of the draft for elliptic curve cryptography in SSH has been >> posted. >> >> http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-06.txt >> >> The main substantive revision is that ecdsa-sha2 is now using a family of >> identifiers (as ecdh-sha2-* does) to specify the curve at the algorithm >> negotiation stage. > > I have to say that I really dislike the Base64(MD5(DER(OID))) encoding > of curve names into the kex method names. Why not just use the SEC names? > Actually, why bake the names into the kex names at all? (as opposed to > sending a curve spec as a parameter). I second this opinion warmly. Method names, whether kex, cipher, mac, or compression should (and in my opinion must) be not only readable but also human readable. If a large number of curves is needed and OID really must be used, then it should be encoded to ascii in some human readable way e.g. "ec-1.2.3.4.5". Still, SEC names would be much more sensible. Anyways, if you assign an OID for each new curve, you can as well assign an unique symbolic name that also somewhat lists the characteristichs of the curve. > The "Security Considerations" section talks about the possible need to > replace SHA2 with other algorithms, but the name "sha2" is baked into > the kex method name. Should the hash algorithm be a parameter too? Maybe it should but MAC in kex has somewhat specific meaning and maybe it should be tied to specific kex name. I don't have a strong opinion here. -- Timo J. Rinne Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 14 08:04: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 954E93A692C for ; Tue, 14 Apr 2009 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.606, 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 BDnq-zAvHWx9 for ; Tue, 14 Apr 2009 08:04:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B7E6E3A659C for ; Tue, 14 Apr 2009 08:04:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1D62A63B2AD; Tue, 14 Apr 2009 15:05:38 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 E733F63B1E4 for ; Tue, 14 Apr 2009 15:05:34 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EF5Oia009917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 11:05:25 -0400 (EDT) Date: Tue, 14 Apr 2009 11:05:24 -0400 From: Jeffrey Hutzelman To: Damien Miller , Douglas Stebila cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: New version: draft-green-secsh-ecc-06 Message-ID: In-Reply-To: References: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Tuesday, April 14, 2009 02:06:48 PM +1000 Damien Miller wrote: > Do the many ECC patent apply to the methods described in this draft? It > seems to lack any section on IPR. It doesn't need a section on IPR; the IETF does not take a position on IPR claims and doesn't formalize such claims in its documents. If the authors hold IPR on the ECC methods referenced in this document, they're obligated to disclose it through the IETF IPR disclosure process, not by mentioning it in a document. I believe that one or more holders of ECC-related IPR have done so already, though probably not with respect to this document, which is relatively new. It is appropriate for a working group to discuss IPR issues when deciding whether to adopt a particular approach, but this is not a working group document and the secsh working group no longer exists. So, feel free to ask questions about the IPR issues, but the document does not need a section addressing them. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 14 08:09: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 AB1223A69C4 for ; Tue, 14 Apr 2009 08:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 bLV0FjXtP3JS for ; Tue, 14 Apr 2009 08:09:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 78A7B3A6847 for ; Tue, 14 Apr 2009 08:09:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A829B63B13F; Tue, 14 Apr 2009 15:10:59 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 52AFD63B291 for ; Tue, 14 Apr 2009 15:10:55 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EFAdCA010155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 11:10:39 -0400 (EDT) Date: Tue, 14 Apr 2009 11:10:39 -0400 From: Jeffrey Hutzelman To: Douglas Stebila , Peter Gutmann cc: djm@mindrot.org, ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: New version: draft-green-secsh-ecc-06 Message-ID: <166FCF7A4C358F5744A27527@atlantis.pc.cs.cmu.edu> In-Reply-To: <441ACB35-9662-48E8-A2DD-CABE45201343@stebila.ca> References: <441ACB35-9662-48E8-A2DD-CABE45201343@stebila.ca> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Tuesday, April 14, 2009 03:53:12 PM +1000 Douglas Stebila wrote: >>> I have to say that I really dislike the Base64(MD5(DER(OID))) >>> encoding of >>> curve names into the kex method names. Why not just use the SEC >>> names? >> >> Oh, so it wasn't just me :-). My reaction to seeing this was "did >> someone >> lose a bet or something...". > > As I mentioned, this was a change that my IETF document shepherd asked me > to make in going from -02 to -03. I agree it's ugly. That was me. The particular encoding I suggested is the same one we used in gss-keyex for GSS-API mechanisms, which are also named by OID's. I agree it's ugly, but I don't know of any better alternatives (ironically, the SASL WG is working on a better alternative for GSS-API mechanisms, too late for us, but it doesn't apply to OID's in general). It would be fine to name the kex methods by names, if there are such, but using an OID encoded in ASCII won't work; OID's can be arbitrarily long and you'll quickly run out of space. >> Having said that, in practice everyone (well, among TLS >> implementors) has >> settled on a small number of popular curves and that's it (which is >> quite >> convenient, you don't even have to worry about extensions, just go >> with P256 >> and everything'll support it). I'd define a few fixed names for the >> well-known curves that everyone ends up using (the NIST ones, >> basically) and >> leave the strange stuff to the usual name@vendor-name mechanism, >> which is >> exactly what it was meant for. > > If the consensus on this mailing list is that using a few fixed names is > fine, then I am willing to make that change. > > My preference would be the following: > > Method names are ecdh-sha2-[identifier] and ecdsa-sha2-[identifier], > where [identifier] is > nistp256 -- REQUIRED (Suite B) > nistp384 -- REQUIRED (Suite B) > Base64(MD5(DER(OID))) -- OPTIONAL > with the additional proviso that, if the curve in question is in fact > nistp256 (== secp256r1) or nistp384 (== secp384r1), then implementations > MUST use the nistp256/nistp384 naming convention and MUST NOT use the > Base64(MD5(DER(OID))) naming convention. > > The rationale for this compromise is as follows. It seems as if we > expect the vast majority of implementations to be aiming for Suite B > which is nistp256 and nistp384. Those implementations need never worry > about the ugly names. For implementations that want to go beyond Suite > B, they can use the ugly (but universal and extensible) names. Note that this is similar to the compromize we made for mod-p DH keyex, where we have fixed names for a few groups, plus a "group exchange" method that allows negotiation of a specific group once the method has been selected. However, that does have the two-level negotiation problem. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 14 08:13:21 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 E4DA23A68ED for ; Tue, 14 Apr 2009 08:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRvAaEbD16Sh for ; Tue, 14 Apr 2009 08:13:21 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D077F3A67D7 for ; Tue, 14 Apr 2009 08:13:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CD66663B1E4; Tue, 14 Apr 2009 15:14:25 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 A54C763B178 for ; Tue, 14 Apr 2009 15:14:24 +0000 (UTC) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EFEHPG010321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 11:14:18 -0400 (EDT) Date: Tue, 14 Apr 2009 11:14:17 -0400 From: Jeffrey Hutzelman To: Douglas Stebila , Damien Miller cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: New version: draft-green-secsh-ecc-06 Message-ID: <03627CAF4A97F5A1ADDD6A64@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <435C04D8-C096-4E58-8745-1770A8388BCD@stebila.ca> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Tuesday, April 14, 2009 02:43:01 PM +1000 Douglas Stebila wrote: >> The "Security Considerations" section talks about the possible need to >> replace SHA2 with other algorithms, but the name "sha2" is baked into >> the kex method name. Should the hash algorithm be a parameter too? > > That's an option, although one that I don't think is worth pursuing at > this point. The SHA-3 competition is a long way from being done, so > SHA-2 is the gold standard right now. If there's a desire to see SHA-3 > adopted in SSH, it would not be hard to create a short RFC indicating > that SHA-3 could be substituted fro SHA-2, and this draft, while not > explicitly saying how to do it, is very suggestive. Well, you'd have to not only substitute SHA-3 for SHA-2, but also change the names, since the two wouldn't interoperate. Including the hash in the kex name is consistent with what we have done in other SSH kex methods, and avoids a multi-level negotiation problem. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 14 09:35:57 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 3A2043A6E35 for ; Tue, 14 Apr 2009 09:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 v9Oy9eqrs2Go for ; Tue, 14 Apr 2009 09:35:56 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 324053A6844 for ; Tue, 14 Apr 2009 09:35:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 10D5D63B2A6; Tue, 14 Apr 2009 16:36: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 19D7F63B18E for ; Tue, 14 Apr 2009 16:36:40 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Tue, 14 Apr 2009 09:32:04 -0700 From: James Blaisdell To: Jeffrey Hutzelman , Douglas Stebila , Peter Gutmann CC: "djm@mindrot.org" , "ietf-ssh@NetBSD.org" Date: Tue, 14 Apr 2009 09:36:35 -0700 Subject: RE: New version: draft-green-secsh-ecc-06 Thread-Topic: New version: draft-green-secsh-ecc-06 Thread-Index: Acm9EplcVyVhFbUDS0mL6UBMDKFu3AACpL/g Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AEB3@yugi.mocana.local> References: <441ACB35-9662-48E8-A2DD-CABE45201343@stebila.ca> <166FCF7A4C358F5744A27527@atlantis.pc.cs.cmu.edu> In-Reply-To: <166FCF7A4C358F5744A27527@atlantis.pc.cs.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I've implemented draft-06: ECDH and ECDSA. It was very simple to refactor = TLS EC code to support SSH. The base64 encoding is ugly, but I agree it's = necessary. IMO - The @domain approach is uglier and the thought of ASCII e= ncoding OIDs is even nastier. Since the base64 encoded OID string is stati= c, I don't bother to decode, I simply know this string maps to a curve. =20 Earlier on this thread, it was suggest that perhaps the client and server c= ould fall back, if the host key type did not match. This would add many mo= re messages to the protocol. I recommended to Douglas to append the base64= to the base type (i.e. ecdsa-sha2-) to avoid this issue. I think = it's the correct approach, and most true to SSH protocol. Adding TLS-like = hello extension would be messier, and break interoperability with all preex= isting implementations in the field. =20 It seems the base64 oid is the only controversial item in this draft. If s= o, it's a minor issue. I would very much like to see this draft version mo= ve to RFC. It's well written, easy to implement, matches other SSH RFCs in= naming convention and feels complete imo. =20 Thank you, James -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Jeffrey Hutzelman Sent: Tuesday, April 14, 2009 8:11 AM To: Douglas Stebila; Peter Gutmann Cc: djm@mindrot.org; ietf-ssh@NetBSD.org; jhutz@cmu.edu Subject: Re: New version: draft-green-secsh-ecc-06 --On Tuesday, April 14, 2009 03:53:12 PM +1000 Douglas Stebila=20 wrote: >>> I have to say that I really dislike the Base64(MD5(DER(OID))) >>> encoding of >>> curve names into the kex method names. Why not just use the SEC >>> names? >> >> Oh, so it wasn't just me :-). My reaction to seeing this was "did >> someone >> lose a bet or something...". > > As I mentioned, this was a change that my IETF document shepherd asked me > to make in going from -02 to -03. I agree it's ugly. That was me. The particular encoding I suggested is the same one we used=20 in gss-keyex for GSS-API mechanisms, which are also named by OID's. I=20 agree it's ugly, but I don't know of any better alternatives (ironically,=20 the SASL WG is working on a better alternative for GSS-API mechanisms, too= =20 late for us, but it doesn't apply to OID's in general). It would be fine to name the kex methods by names, if there are such, but=20 using an OID encoded in ASCII won't work; OID's can be arbitrarily long and= =20 you'll quickly run out of space. >> Having said that, in practice everyone (well, among TLS >> implementors) has >> settled on a small number of popular curves and that's it (which is >> quite >> convenient, you don't even have to worry about extensions, just go >> with P256 >> and everything'll support it). I'd define a few fixed names for the >> well-known curves that everyone ends up using (the NIST ones, >> basically) and >> leave the strange stuff to the usual name@vendor-name mechanism, >> which is >> exactly what it was meant for. > > If the consensus on this mailing list is that using a few fixed names is > fine, then I am willing to make that change. > > My preference would be the following: > > Method names are ecdh-sha2-[identifier] and ecdsa-sha2-[identifier], > where [identifier] is > nistp256 -- REQUIRED (Suite B) > nistp384 -- REQUIRED (Suite B) > Base64(MD5(DER(OID))) -- OPTIONAL > with the additional proviso that, if the curve in question is in fact > nistp256 (=3D=3D secp256r1) or nistp384 (=3D=3D secp384r1), then implemen= tations > MUST use the nistp256/nistp384 naming convention and MUST NOT use the > Base64(MD5(DER(OID))) naming convention. > > The rationale for this compromise is as follows. It seems as if we > expect the vast majority of implementations to be aiming for Suite B > which is nistp256 and nistp384. Those implementations need never worry > about the ugly names. For implementations that want to go beyond Suite > B, they can use the ugly (but universal and extensible) names. Note that this is similar to the compromize we made for mod-p DH keyex,=20 where we have fixed names for a few groups, plus a "group exchange" method= =20 that allows negotiation of a specific group once the method has been=20 selected. However, that does have the two-level negotiation problem. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 01:55:58 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 CDF713A6403 for ; Wed, 15 Apr 2009 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044] 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 n6UYBfHyAY2v for ; Wed, 15 Apr 2009 01:55:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 70A983A659C for ; Wed, 15 Apr 2009 01:55:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B65163B375; Wed, 15 Apr 2009 08:56:47 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from kissez893.easyvserver.com (kissez893.easyvserver.com [62.233.81.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "plesk", Issuer "plesk" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id 9645D63B36E for ; Wed, 15 Apr 2009 08:56:44 +0000 (UTC) Received: (qmail 5503 invoked by uid 48); 15 Apr 2009 06:54:32 +0100 Message-ID: <20090415055432.5494.qmail@kissez893.easyvserver.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.117 (F2.74) Date: Wed, 15 Apr 2009 05:54:32 UT From: Mark Rozsahegyi To: Ietf Ssh 1 Subject: adja s ne hagyja Reply-To: nevess@nevetosok.hu Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list :-) Ha Ön optimista azért, ha kevésbé azért segítsen, adója mindkét 1%-ának felajánlásával, szervezeteink számára! Adója elsõ 1%-át kérjük adja az "1 8 1 6 1 9 1 1 - 1 - 4 1" (EOM Alapítvány), a második 1%-ot a "1 5 2 4" technikai számú D e r û Egyháznak, hogy a két szervezet együttmûködéseként, megvalósuljon az átlátható adományozás. Ne hagyja a második 1%-ot az államban, adja a rászorulóknak "1 5 2 4". Köszönjük! Legyen szép és derûs a napja! (-: Pozitív kezdeményezéseinkrõl tájékoztatjuk, amennyiben ide kattint: http://nevetosok.hu/cgi-bin/register.cgi?act=m&list=8&sub=cniihpa0QKk6 Nem küldünk több levelet, amennyiben ezt jelzi számunkra: http://nevetosok.hu/cgi-bin/register.cgi?un=cniihpa0QKk6 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 01:56:00 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 6B4503A6403 for ; Wed, 15 Apr 2009 01:56:00 -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 AobwbIn7Gx5Z for ; Wed, 15 Apr 2009 01:55:59 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 53E793A6B04 for ; Wed, 15 Apr 2009 01:55:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2020A63B371; Wed, 15 Apr 2009 08:56:58 +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 9A08263B36E for ; Wed, 15 Apr 2009 08:56:50 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CB75B4001C; Wed, 15 Apr 2009 10:56:33 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id C01454002B; Wed, 15 Apr 2009 10:56:33 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 953B54001C; Wed, 15 Apr 2009 10:56:33 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3F8uki4012199; Wed, 15 Apr 2009 10:56:46 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3F8ug2E012194; Wed, 15 Apr 2009 10:56:42 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Tim Polk Cc: ietf-ssh@netbsd.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 10:56:41 +0200 In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> (Tim Polk's message of "Wed, 8 Apr 2009 09:02:00 -0400") 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 Tim Polk writes: > The second solution (sending packet_length unencrypted) has a number > of desirable properties: it conforms to RFC 5116 so the design should > apply to any AEAD algorithm, and it is consistent with the algorithm > specification (NIST SP 800-38D). I have tried to review most of this lengthy discussion, and after some thinking, my conclusion is that optionally having unencrypted length fields is a bad idea. There seem to be two arguments for clear-text lengths: 1. "I never liked the encrypted lengths, I think the TLS protocol design is better". 2. It causes additional complexity when implementing AEAD. I don't find (1) convincing. I'd prefer not to make design changes of this type at this time, unless there's some really, really good reason. I'd not be surprised if there are some applications that rely on the ssh protocol feature that message lengths are encrypted, and are weakened if we change this. (I'd still appreciate to hear more details on what security problems others see with encrypted length fields, though). I find (2) extremely unconvincing, since the proposed solutions are additional levels of negotiation which adds a lot more complexity than it removes. I strongly dislike having several options for how the transport layer should work, I do *not* want to have that extra complexity at this level. One of the options will inevitably be less well-tested and more buggy than the other. I'd like to propose the following guide-lines for using algorithms in the AEAD-class with ssh: 1. The algorithm is specified as an encryption algorithm in the kexinit message. The mac should be set to "none" (or must? If we allow other values, that should mean that some other MAC is used in addition to the AEAD, which causes no big problem in principle but it seems to be of limited usefulness. (There are some details left to specify on exactly how this should interact with algorithm selection, since there are additional dependencies. You want to be able to ask for (aead, none) with a fallback to (3des-cbc, hmac), without risk of ending up with (3des-cbc, none). Maybe it's easier to say that if an AEAD-algorithm is chosen for encryption, the lists of mac algorithms (for that direction) are ignored). 2. The first block of each message is encrypted using a separately keyed cipher. For AES-GCM, this could be AES in counter mode. For proper authentication, the clear text for this block is included in the "associated data" for AEAD, together with the implicit sequence number, and any other context data that needs authentication. (A slight elaboration of Damien Miller's idea). The choice for the cipher for the first block should of course be chosen so that it reuses the same primitives as the AEAD-algorithm that is used. 3. The rest of the message (as determined by the length and padding fields contained in the first block) holds the AEAD ciphertext. For me, it would probably work just fine to implement AEAD so that I can get the result for the first block before reading the rest of the data, but the above construction avoids this requirement on the AEAD interface, so I suspect some of you will find it cleaner. The primary objective of this proposal is to keep things simple and minimalistic. Does it make sense? Am I missing some complication that must be dealt with? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 03:13: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 6DD7B3A6AA8 for ; Wed, 15 Apr 2009 03:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.029 X-Spam-Level: X-Spam-Status: No, score=-8.029 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_20=-0.74, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_34=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 X7xnCiKXGPqW for ; Wed, 15 Apr 2009 03:13:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 9974A3A6917 for ; Wed, 15 Apr 2009 03:13:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E9E5063B1BF; Wed, 15 Apr 2009 10:14:36 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 6F07163B159 for ; Wed, 15 Apr 2009 10:14:33 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id GAA28779; Wed, 15 Apr 2009 06:14:33 -0400 (EDT) From: der Mouse Message-Id: <200904151014.GAA28779@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, 15 Apr 2009 06:10:50 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > (There are some details left to specify on exactly how this should > interact with algorithm selection, since there are additional > dependencies. You want to be able to ask for (aead, none) with a > fallback to (3des-cbc, hmac), without risk of ending up with > (3des-cbc, none). I believe that's not directly possible at present, given the way algorithm negotiation works. However, it is fairly easy to offer enc=aead,3des-cbc mac=hmac, and, if that negotiation succeeds, immediately re-kex with enc=aead mac=none. > Maybe it's easier to say that if an AEAD-algorithm is chosen for > encryption, the lists of mac algorithms (for that direction) are > ignored). That would be a rather unpleasant violation of the existing definition. I'd much rather just re-kex if using a none MAC is that important. /~\ 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 Apr 15 04:32: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 30F533A6B32 for ; Wed, 15 Apr 2009 04:32:31 -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_34=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 gMDBbH5NkKEY for ; Wed, 15 Apr 2009 04:32:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CD63C3A6403 for ; Wed, 15 Apr 2009 04:32:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 995F863B13A; Wed, 15 Apr 2009 11:33:33 +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 1E05363B159 for ; Wed, 15 Apr 2009 11:33:30 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2279A40037; Wed, 15 Apr 2009 13:33:15 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 1617640039; Wed, 15 Apr 2009 13:33:15 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 8921240037; Wed, 15 Apr 2009 13:33:14 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FBXRxb017889; Wed, 15 Apr 2009 13:33:27 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FBXQ0J017888; Wed, 15 Apr 2009 13:33:26 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 13:33:25 +0200 In-Reply-To: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Wed, 15 Apr 2009 06:10:50 -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: > However, it is fairly easy to offer enc=aead,3des-cbc mac=hmac, and, if > that negotiation succeeds, immediately re-kex with enc=aead mac=none. I'd consider it a spectacular failure of the ssh-with-aead specification if use of AEAD in the intended way (as both encryption and mac, with no additional mac) requires two rounds of keyexchange at connection startup. This gives unnececssary costs in both roundtrips and computation, as well as in the implementation complexity that comes with an extra negotiation round. > That would be a rather unpleasant violation of the existing definition. Well, the current rules are based on the assumption that encryption and mac are independent (and that all algorithms can be selected independently, except for a somewhat vague dependency between key-exchange algorithm and hostkey algorithm). With aead, this assumption is not quite valid. I can understand your concern, but I think it's quite natural to require that if an implementation supports and advertises an aead algorithm, then it is aware that selecting aead for encryption makes the selection of mac algorithm moot. We won't get into any real trouble for doing that until we also specify that if a particular mac algorithm is used, the encryption algorithm should be ignored. And we won't do that, if we agree that any algorithms with intimate dependencies between encryption and mac should go inte the encryption list rather than the mac list. Analogously, if we specify a keyexchange algorithm with integrated server authentication (say, using SRP or something like that for the key exchange), we can say that the hostkey algorithm is moot and ignored. > I'd much rather just re-kex if using a none MAC is that important. I also find it brittle to renegotiate with a subset of the previous algorithms, in particular when you exclude one of the *selected* algorithms. Imagine that both sides attempt renegotiation, and that they do it slightly differently. Then the connection may fall apart. And if you want to avoid such problems by specifying in more detail what the policy behind the renegotiation should be, then I'd much prefer to specify *explicitly* what it is you want to achieve, e.g., that no mac should be used together with AEAD, and then implement that policy at both ends with no extra negotiation. BTW, I'm also curious about the motivation for the GCM mode. I just had a first reading of the spec (http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf). The structure is almost the same as CTR mode with a separate MAC. The only way I can make sense of it is if (i) GHASH is significantly faster than common macs such as hmac-sha1, and (ii) GHASH has properties that make it usable for GCM, but not suited for use as an independent MAC. Is that the case, or what's the point? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 05:20:21 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 6E5A428C141 for ; Wed, 15 Apr 2009 05:20:21 -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=[AWL=0.000, 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 S0Ewcas14TOG for ; Wed, 15 Apr 2009 05:20:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A52E028C14F for ; Wed, 15 Apr 2009 05:20:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 00A9B63B17B; Wed, 15 Apr 2009 12:21:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id BBB4E63B176 for ; Wed, 15 Apr 2009 12:21:28 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 5C3DAC4B9F; Wed, 15 Apr 2009 22:21:26 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id DF795C4AF4; Wed, 15 Apr 2009 22:21:20 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 31F80A4F54; Wed, 15 Apr 2009 22:21:20 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 301B2A4F51; Wed, 15 Apr 2009 22:21:20 +1000 (EST) Date: Wed, 15 Apr 2009 22:21:20 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, der Mouse wrote: > > Maybe it's easier to say that if an AEAD-algorithm is chosen for > > encryption, the lists of mac algorithms (for that direction) are > > ignored). > > That would be a rather unpleasant violation of the existing definition. > I'd much rather just re-kex if using a none MAC is that important. Without offering a solution to the initial negotiation (all that I have seen so far a ugly), I would observe that rekex is far to expensive to be a good solution to this problem. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 05:50:06 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 D04843A6AA0 for ; Wed, 15 Apr 2009 05:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, 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 2-sAUfcTC7Ra for ; Wed, 15 Apr 2009 05:50:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 87C883A6E5D for ; Wed, 15 Apr 2009 05:50:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C54F963B18B; Wed, 15 Apr 2009 12:50:35 +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 798A363B1DB for ; Wed, 15 Apr 2009 12:50:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 950FE668130; Thu, 16 Apr 2009 00:50:18 +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 cJouWluL0DA3; Thu, 16 Apr 2009 00:50:18 +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 B48F26680E6; Thu, 16 Apr 2009 00:50:15 +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 BCC341DE4001; Thu, 16 Apr 2009 00:50:09 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lu4Z7-0001jy-J4; Thu, 16 Apr 2009 00:50:09 +1200 From: Peter Gutmann To: douglas@stebila.ca, jhutz@cmu.edu, pgut001@cs.auckland.ac.nz Subject: Re: New version: draft-green-secsh-ecc-06 Cc: djm@mindrot.org, ietf-ssh@NetBSD.org In-Reply-To: <166FCF7A4C358F5744A27527@atlantis.pc.cs.cmu.edu> Message-Id: Date: Thu, 16 Apr 2009 00:50:09 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Jeffrey Hutzelman writes: >It would be fine to name the kex methods by names, if there are such, but >using an OID encoded in ASCII won't work; OID's can be arbitrarily long and >you'll quickly run out of space. They can in theory be arbitrarily long, but no-one ever uses them that way, the longest ones that I'm aware of in crypto use are 20-25 characters, which puts the extreme, worst-case OIDs in the same range as standard MD5-in-ASCII. If they're OIDs encoded as ASCII then if someone sends you a new value that you've never seen before all you need to do is cut and paste it into Google to find the curve. If you put the binary value through a *one-way* hash function there's no way you can ever figure out what some string of base64 that you're seeing actually started out as, and therefore no way to locate the curve unless you've already got a copy to hand whose hash you can compare with (and even then you need to do a brute-force search to figure out which value's hash you're seeing). Non-reversible hash functions are great for what they were designed for, creating fingerprints of documents for signing. They're less useful when you need to map them back to the data they were created from. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 05:50: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 6E3D53A6DC9 for ; Wed, 15 Apr 2009 05:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 MJ1ptpPwK6Cj for ; Wed, 15 Apr 2009 05:50:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 635513A6909 for ; Wed, 15 Apr 2009 05:50:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D30263B122; Wed, 15 Apr 2009 12:51:33 +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 0579363B17F for ; Wed, 15 Apr 2009 12:51:30 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 05:46:53 -0700 From: James Blaisdell To: =?iso-8859-1?Q?Niels_M=F6ller?= , Tim Polk CC: "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Date: Wed, 15 Apr 2009 05:51:24 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm9p4BWa45F0MLyRCatxMvecPMq4wAHcTDw Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> 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 Precedence: list Hello, I can live with cleartext length field or encrypted length field. I have i= mplemented AES-GCM as the draft stands now, so I know it's technically poss= ible. It has been suggested that some AES-GCM implementations must process= the message as a single block of data --- a black box. I don't know what = hardware offload (proprietary?) that is unable to process AES-GCM in a chun= k manner; Cavium can process in chunks. I suppose at some point in the fut= ure an AEAD-* method will not be able to process the message in chunks, but= this draft is for AEAD-AES-GCM. Are we trying to future proof something t= hat may never happen? Even so, I would imagine it could dealt with at that= time --- there will be an inconsistency now or future. =20 I do agree sending the length field in the clear will cause some headaches = at a lowest level, since a new in/out method will need to be written and te= sted. However, I don't see the issues around NEWKEY some have suggested, b= ut perhaps that implementation specific. The encrypted length field has be= en a pain in the past, especially for async implementations like mine, but = I have lived with it fine for last few years. =20 The only issue I have any energy around are suggestions for fallback approa= ches or no-MAC; similar approaches have been suggested for SSH-ECDSA. Thes= e approaches create a great deal of work and break the current protocol mod= el. =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: Wednesday, April 15, 2009 1:57 AM To: Tim Polk Cc: ietf-ssh@netbsd.org; Tero Kivinen; Bill Sommerfeld; Chris Lonvick; ylo@= ssh.com; Igoe, Kevin M.; Jerome A. Solinas; Eronen Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Tim Polk writes: > The second solution (sending packet_length unencrypted) has a number > of desirable properties: it conforms to RFC 5116 so the design should > apply to any AEAD algorithm, and it is consistent with the algorithm > specification (NIST SP 800-38D). I have tried to review most of this lengthy discussion, and after some thinking, my conclusion is that optionally having unencrypted length fields is a bad idea. There seem to be two arguments for clear-text lengths: 1. "I never liked the encrypted lengths, I think the TLS protocol design is better". 2. It causes additional complexity when implementing AEAD. I don't find (1) convincing. I'd prefer not to make design changes of this type at this time, unless there's some really, really good reason. I'd not be surprised if there are some applications that rely on the ssh protocol feature that message lengths are encrypted, and are weakened if we change this. (I'd still appreciate to hear more details on what security problems others see with encrypted length fields, though). I find (2) extremely unconvincing, since the proposed solutions are additional levels of negotiation which adds a lot more complexity than it removes. I strongly dislike having several options for how the transport layer should work, I do *not* want to have that extra complexity at this level. One of the options will inevitably be less well-tested and more buggy than the other. I'd like to propose the following guide-lines for using algorithms in the AEAD-class with ssh: 1. The algorithm is specified as an encryption algorithm in the kexinit message. The mac should be set to "none" (or must? If we allow other values, that should mean that some other MAC is used in addition to the AEAD, which causes no big problem in principle but it seems to be of limited usefulness. (There are some details left to specify on exactly how this should interact with algorithm selection, since there are additional dependencies. You want to be able to ask for (aead, none) with a fallback to (3des-cbc, hmac), without risk of ending up with (3des-cbc, none). Maybe it's easier to say that if an AEAD-algorithm is chosen for encryption, the lists of mac algorithms (for that direction) are ignored). 2. The first block of each message is encrypted using a separately keyed cipher. For AES-GCM, this could be AES in counter mode. For proper authentication, the clear text for this block is included in the "associated data" for AEAD, together with the implicit sequence number, and any other context data that needs authentication. (A slight elaboration of Damien Miller's idea). The choice for the cipher for the first block should of course be chosen so that it reuses the same primitives as the AEAD-algorithm that is used. 3. The rest of the message (as determined by the length and padding fields contained in the first block) holds the AEAD ciphertext. For me, it would probably work just fine to implement AEAD so that I can get the result for the first block before reading the rest of the data, but the above construction avoids this requirement on the AEAD interface, so I suspect some of you will find it cleaner. The primary objective of this proposal is to keep things simple and minimalistic. Does it make sense? Am I missing some complication that must be dealt with? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 06:11:05 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 69E7A3A6E72 for ; Wed, 15 Apr 2009 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 vBE6hXZ+ypLA for ; Wed, 15 Apr 2009 06:11:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0E32C3A6E14 for ; Wed, 15 Apr 2009 06:10:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F7F563B1A7; Wed, 15 Apr 2009 13:11:47 +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 0490163B190 for ; Wed, 15 Apr 2009 13:11:44 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 06:07:06 -0700 From: James Blaisdell To: Peter Gutmann , "douglas@stebila.ca" , "jhutz@cmu.edu" CC: "djm@mindrot.org" , "ietf-ssh@NetBSD.org" Date: Wed, 15 Apr 2009 06:11:40 -0700 Subject: RE: New version: draft-green-secsh-ecc-06 Thread-Topic: New version: draft-green-secsh-ecc-06 Thread-Index: Acm9yDrkgRX2vdGrQXKNHFqUiD+PAQAATn2A Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF22@yugi.mocana.local> References: <166FCF7A4C358F5744A27527@atlantis.pc.cs.cmu.edu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hello, For my implementation, it would be trivial to have some ECDH/ECDSA methods = name with ASCII OID, an English name, or a Base64 encoded OID. I would ima= gine most people would use a table driven model, as we have done. The firs= t field is debug string name, second is the on the wire algo negotiation st= ring, length of algo string, etc. I simply need to change that one field, = so mixing would be fine --- some could use one naming convention and others= could use the base64 for future proofing. =20 Here is a row from my table: { (sbyte *)"ecdh-sha2-secp521r1", (sbyte *)"ecdh-sha2-h/SsxnLCtRBh7I9AT= yeB3A=3D=3D", 34, cid_EC_P521, &ecdhMethods, &sshHandshakeSHA512, se= cp521r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH }, Here are the beauty contestants: { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-scep256r1", = 19, cid_EC_P256, &ecdhMethods, &sshHandshakeSHA256, secp25= 6r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH }, { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-1.2.840.10045.3.1= .7", 29, cid_EC_P256, &ecdhMethods, &sshHandshakeSHA256, secp25= 6r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH }, { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-9UzNcgwTlEnSCECZa= 7V1mw=3D=3D", 34, cid_EC_P256, &ecdhMethods, &sshHandshakeSHA256, se= cp256r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH }, With table driven approach, I can actually leave all three of these naming = conventions in the same table. Mixing would be fine. This seems to be mor= e of cosmetic question than technical issue. Is it A, B or C? =20 Thank you, James -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Peter Gutmann Sent: Wednesday, April 15, 2009 5:50 AM To: douglas@stebila.ca; jhutz@cmu.edu; pgut001@cs.auckland.ac.nz Cc: djm@mindrot.org; ietf-ssh@NetBSD.org Subject: Re: New version: draft-green-secsh-ecc-06 Jeffrey Hutzelman writes: >It would be fine to name the kex methods by names, if there are such, but >using an OID encoded in ASCII won't work; OID's can be arbitrarily long an= d >you'll quickly run out of space. They can in theory be arbitrarily long, but no-one ever uses them that way, the longest ones that I'm aware of in crypto use are 20-25 characters, whic= h puts the extreme, worst-case OIDs in the same range as standard MD5-in-ASCI= I. If they're OIDs encoded as ASCII then if someone sends you a new value that you've never seen before all you need to do is cut and paste it into Google= to find the curve. If you put the binary value through a *one-way* hash funct= ion there's no way you can ever figure out what some string of base64 that you'= re seeing actually started out as, and therefore no way to locate the curve unless you've already got a copy to hand whose hash you can compare with (a= nd even then you need to do a brute-force search to figure out which value's h= ash you're seeing). Non-reversible hash functions are great for what they were designed for, creating fingerprints of documents for signing. They're less useful when you need to map them back to the data they were created from. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 07:29: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 C04B228C21F for ; Wed, 15 Apr 2009 07:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CdvTJADynXrC for ; Wed, 15 Apr 2009 07:29:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CE0F528C1C4 for ; Wed, 15 Apr 2009 07:29:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AFB5363B1C5; Wed, 15 Apr 2009 14:30:27 +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 6275463B17F for ; Wed, 15 Apr 2009 14:30:25 +0000 (UTC) Received: from Atlantic ([69.57.253.76]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 15 Apr 2009 09:29:52 -0400 Message-ID: From: "denis bider \(Bitvise\)" To: "James Blaisdell" , =?iso-8859-1?Q?Niels_M=F6ller?= , "Tim Polk" Cc: , "Tero Kivinen" , "Bill Sommerfeld" , "Chris Lonvick" , , "Igoe, Kevin M." , "Jerome A. Solinas" , References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Date: Wed, 15 Apr 2009 09:29:27 -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.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I've been seeing this argument enough that I need to comment on it: > The encrypted length field has been a pain in the past, especially > for async implementations like mine, but I have lived with it fine for > last few years. - We have TWO fully asynchronous SSH implementations, and the encrypted length field has not been an implementation problem for either of them. - Introducing a new way of sending length unencrypted is not going to relieve programmers of the burden of implementing the encrypted length. If anything, it's going to add a NEW burden of having to support two ways of sending and receiving the length, encrypted and unencrypted. - The one problem I know of with sending the length encrypted is that it has facilitated a plaintext discovery attack when used with CBC. The proper response to that is to (1) prefer CTR mode, and (2) implement length decoding in a way that defeats the attack. That being said: I have no problem with the AEAD implementation doing whatever it wants, as long as implementations that don't want to use AEAD are unaffected. It sounds like AEAD is sufficiently different that it _requires_ modifying the transport layer for sensible implementation. At the very least, for example, it needs to introduce a dependency that will implicitly turn off the MAC algorithm when AEAD is used. If I were implementing AEAD, however, I would also worry about any possible implementations that might be relying on the SSH packet boundary not being obviously disclosed, and would worry about AEAD's compatibility with such applications. This seems to gesture that continuing to implement an encrypted payload field may be a good idea even with AEAD. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 08:28: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 3B6D13A6A56 for ; Wed, 15 Apr 2009 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 1Sn4JC6NOELT for ; Wed, 15 Apr 2009 08:28:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id EED2628C21D for ; Wed, 15 Apr 2009 08:28:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A148963B1A0; Wed, 15 Apr 2009 15:29:14 +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 EA4A563B182 for ; Wed, 15 Apr 2009 15:29:12 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 08:24:35 -0700 From: James Blaisdell To: "denis bider (Bitvise)" , =?iso-8859-1?Q?Niels_M=F6ller?= , Tim Polk CC: "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , "Pasi.Eronen@nokia.com" Date: Wed, 15 Apr 2009 08:29:09 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm9zYi+gq6lFZTfR9aSQp5IopubXwADr8rA Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF32@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@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 Precedence: list Hello, > It sounds like AEAD is sufficiently different that it=20 > _requires_ modifying the transport layer for sensible implementation. This is true for the generic case of AEAD-*, but not true for AEAD-AES-GCM.= AEAD-AES-GCM works fine per draft. I want to stress it can be made to wo= rk, including the MAC --- AEAD-AES-GMAC. AEAD-AES-GCM using same cryptogra= phic AES-GCM used by our TLS 1.2 implementation was reused with SSH. The a= lgorithm was quite simple to adopt. I spent some extra effort to verify th= at message chunks were not an issue (mainly due to what I had read online t= his being an issue). I was not the author of our AES-GCM implementation, a= nd I didn't need to consult him --- it was fairly effortless to integrate. = =20 I'd like to see Suite B related drafts move forward. IMO - We're down to o= ne small issue on each that are blocking final consensus. I am fine with a= dding support for clear text length field, if this means we can move to fin= al RFC --- although I personally don't believe it's necessary work at this = time to support AEAD-AES-GCM. =20 Btw There has been a couple of important SSH drafts that have stalled, whic= h is a shame. And which I would like to pick up and resurrect. =20 Thank you, James -----Original Message----- From: denis bider (Bitvise) [mailto:ietf-ssh2@denisbider.com]=20 Sent: Wednesday, April 15, 2009 6:29 AM To: James Blaisdell; Niels M=F6ller; Tim Polk Cc: ietf-ssh@netbsd.org; Tero Kivinen; Bill Sommerfeld; Chris Lonvick; ylo@= ssh.com; Igoe, Kevin M.; Jerome A. Solinas; Pasi.Eronen@nokia.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" I've been seeing this argument enough that I need to comment on it: > The encrypted length field has been a pain in the past, especially > for async implementations like mine, but I have lived with it fine for=20 > last few years. - We have TWO fully asynchronous SSH implementations, and the encrypted=20 length field has not been an implementation problem for either of them. - Introducing a new way of sending length unencrypted is not going to=20 relieve programmers of the burden of implementing the encrypted length. If= =20 anything, it's going to add a NEW burden of having to support two ways of=20 sending and receiving the length, encrypted and unencrypted. - The one problem I know of with sending the length encrypted is that it ha= s=20 facilitated a plaintext discovery attack when used with CBC. The proper=20 response to that is to (1) prefer CTR mode, and (2) implement length=20 decoding in a way that defeats the attack. That being said: I have no problem with the AEAD implementation doing=20 whatever it wants, as long as implementations that don't want to use AEAD=20 are unaffected. It sounds like AEAD is sufficiently different that it=20 _requires_ modifying the transport layer for sensible implementation. At th= e=20 very least, for example, it needs to introduce a dependency that will=20 implicitly turn off the MAC algorithm when AEAD is used. If I were implementing AEAD, however, I would also worry about any possible= =20 implementations that might be relying on the SSH packet boundary not being= =20 obviously disclosed, and would worry about AEAD's compatibility with such=20 applications. This seems to gesture that continuing to implement an=20 encrypted payload field may be a good idea even with AEAD. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 08:35: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 D244C3A6B53 for ; Wed, 15 Apr 2009 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.938 X-Spam-Level: X-Spam-Status: No, score=-8.938 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_34=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 2GDcgarkS5NA for ; Wed, 15 Apr 2009 08:35:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 895373A6AD2 for ; Wed, 15 Apr 2009 08:35:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 72DF963B1E4; Wed, 15 Apr 2009 15:36:37 +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 309E463B1D4 for ; Wed, 15 Apr 2009 15:36:34 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA00772; Wed, 15 Apr 2009 11:36:29 -0400 (EDT) From: der Mouse Message-Id: <200904151536.LAA00772@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, 15 Apr 2009 11:10:57 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> However, it is fairly easy to offer enc=aead,3des-cbc mac=hmac, and, >> if that negotiation succeeds, immediately re-kex with enc=aead >> mac=none. > I'd consider it a spectacular failure of the ssh-with-aead > specification if use of AEAD in the intended way (as both encryption > and mac, with no additional mac) requires two rounds of keyexchange > at connection startup. There's not much choice, though, unless you either (a) break the existing protocol design (eg, by having some encryption algorithms, when chosen, magically rewrite the rules for MAC algortihm selection) or (b) risk ending up with a bad match (like 3des-cbc/none). >> That would be a rather unpleasant violation of the existing >> definition. > Well, the current rules are based on the assumption that encryption > and mac are independent Right. This is a bad match for AEAD. Experimental protocol redesign work (coming up with a good way to tie algorithms together for negotiation) is a sane idea. Trying to shoehorn it into the existing protocol with magic level-violating semantics for certain algorthm names is not. IMO, of course. If ssh starts going down that road, another dozen or so "special cases" later it'll be a horrible mess of magic interdependencies, with determining whether negotiation _can_ succeed bordering on NP-hard. > (and that all algorithms can be selected independently, except for a > somewhat vague dependency between key-exchange algorithm and hostkey > algorithm). What's vague about it? kex may need signatures and/or encryption; host key algorithms may provide signatures and/or encryption; host-key algorithms that don't provide what the negotiated kex algorithm needs are effectively removed from the algorithms lists. (4253 7.1, p. 18.) > I can understand your concern, but I think it's quite natural to > require that if an implementation supports and advertises an aead > algorithm, then it is aware that selecting aead for encryption makes > the selection of mac algorithm moot. That's reasonable. The problem is, the protocol we have has no way to express it. I see three choices: (1) we can suffer an inefficiency necessitated by this mismatch; (2) we can go back into experimental protocol design to come up with a protocol that supports such dependencies properly; (3) we can violate the existing protocol with a magic interdependency and hope it doesn't break anything too badly. (3) is what I wish to discourage. It's just begging for trouble down the line. > We won't get into any real trouble for doing that until we also > specify that if a particular mac algorithm is used, the encryption > algorithm should be ignored. Or some other set of cross-linked magic dependencies end up requiring something effectively similar. If we do this, it won't be the last such piece of negotiation magic, I'm sure of that. >> I'd much rather just re-kex if using a none MAC is that important. > I also find it brittle to renegotiate with a subset of the previous > algorithms, in particular when you exclude one of the *selected* > algorithms. Imagine that both sides attempt renegotiation, and that > they do it slightly differently. Then the connection may fall apart. Yes; buggy code can break things. This has always been true and always will be. I don't think requiring any implementation that supports enc=aead to also support mac=none, at least when using enc=aead, is unreasonable. I certainly consider it less bad than violating the existing algorithm negotiation protocol. I think my preference for doing this within the existing protocol framework would be a "suppress-mac" option (to dig out the options-packets subthread), with AEAD-supporting implementations expected to use it if AEAD is chosen for encryption. /~\ 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 Apr 15 08:44: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 4DBF13A68DA for ; Wed, 15 Apr 2009 08:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.256 X-Spam-Level: X-Spam-Status: No, score=-9.256 tagged_above=-999 required=5 tests=[AWL=0.732, 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 03Nk6-AQe-II for ; Wed, 15 Apr 2009 08:44:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7641628C134 for ; Wed, 15 Apr 2009 08:44:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1D09B63B17F; Wed, 15 Apr 2009 15:45:38 +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 B793863B18C for ; Wed, 15 Apr 2009 15:45:36 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA00861; Wed, 15 Apr 2009 11:45:36 -0400 (EDT) From: der Mouse Message-Id: <200904151545.LAA00861@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, 15 Apr 2009 11:43:54 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Without offering a solution to the initial negotiation (all that I > have seen so far a ugly), I would observe that rekex is far to > expensive to be a good solution to this problem. Agreed. It's just the only solution I see that works within the existing protocol. (IMO the _right_ answer is to invent/design a protocol that allows algorithms to be tied together for negotiation.) /~\ 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 Apr 15 08:44:43 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 77E2E3A68DA for ; Wed, 15 Apr 2009 08:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.196, 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 FIPq1WBXqP4t for ; Wed, 15 Apr 2009 08:44:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 68A2C3A6B93 for ; Wed, 15 Apr 2009 08:44:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A9D5E63B207; Wed, 15 Apr 2009 15:45:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id E08A263B18C for ; Wed, 15 Apr 2009 15:45:45 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FFjgRu011724 for ; Wed, 15 Apr 2009 15:45:42 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 n3FFjfix034959 for ; Wed, 15 Apr 2009 09:45:41 -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 n3FFaGTp011466; Wed, 15 Apr 2009 10:36:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FFa8t6011465; Wed, 15 Apr 2009 10:36:08 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 10:36:08 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415153608.GL1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 06:10:50AM -0400, der Mouse wrote: > > Maybe it's easier to say that if an AEAD-algorithm is chosen for > > encryption, the lists of mac algorithms (for that direction) are > > ignored). > > That would be a rather unpleasant violation of the existing definition. > I'd much rather just re-kex if using a none MAC is that important. AEAD cipher modes clearly combine the MAC into the cipher. That means that the MAC can no longer be negotiated separately from the cipher. Therefore I believe Niels is correct: when an AEAD cipher is selected then the MAC negotiation MUST be ignored. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 08:55: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 9E6E23A69E7 for ; Wed, 15 Apr 2009 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 s4PNWtMPM3et for ; Wed, 15 Apr 2009 08:55:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C0B523A6936 for ; Wed, 15 Apr 2009 08:55:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BE49363B231; Wed, 15 Apr 2009 15:56:34 +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 7F7A563B1CA for ; Wed, 15 Apr 2009 15:56:32 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 08:51:54 -0700 From: James Blaisdell To: Nicolas Williams , der Mouse CC: "ietf-ssh@NetBSD.org" Date: Wed, 15 Apr 2009 08:56:28 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm94J6D4/Vs4VHcTGG9kxr0RY3q6AAAchxg Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> In-Reply-To: <20090415153608.GL1500@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list It doesn't need to be ignored, but the order does matter. AEAD-* algorithm= s must appear first in the order list. And AEAD-* algos must match cipher = and MAC in order as well. It's easy to detect, if there is a mismatch betw= een cipher and hmac. =20 -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Nicolas Williams Sent: Wednesday, April 15, 2009 8:36 AM To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" On Wed, Apr 15, 2009 at 06:10:50AM -0400, der Mouse wrote: > > Maybe it's easier to say that if an AEAD-algorithm is chosen for > > encryption, the lists of mac algorithms (for that direction) are > > ignored). >=20 > That would be a rather unpleasant violation of the existing definition. > I'd much rather just re-kex if using a none MAC is that important. AEAD cipher modes clearly combine the MAC into the cipher. That means that the MAC can no longer be negotiated separately from the cipher. Therefore I believe Niels is correct: when an AEAD cipher is selected then the MAC negotiation MUST be ignored. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 09:24: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 B26403A6BBB for ; Wed, 15 Apr 2009 09:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[AWL=0.195, 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 gUBJBBoZZc9y for ; Wed, 15 Apr 2009 09:24:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8E5BB3A6B9E for ; Wed, 15 Apr 2009 09:24:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4630B63B26A; Wed, 15 Apr 2009 16:25:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id 21F8C63B24A for ; Wed, 15 Apr 2009 16:24:55 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FGOtjj022848 for ; Wed, 15 Apr 2009 16:24:55 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 n3FGOtb4002695 for ; Wed, 15 Apr 2009 10:24:55 -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 n3FG80Cj011595; Wed, 15 Apr 2009 11:08:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FG80WN011594; Wed, 15 Apr 2009 11:08:00 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 11:08:00 -0500 From: Nicolas Williams To: James Blaisdell Cc: der Mouse , "ietf-ssh@NetBSD.org" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415160759.GN1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 08:56:28AM -0700, James Blaisdell wrote: Nico> AEAD cipher modes clearly combine the MAC into the cipher. That Nico> means that the MAC can no longer be negotiated separately from the Nico> cipher. Nico> Therefore I believe Niels is correct: when an AEAD cipher is selected Nico> then the MAC negotiation MUST be ignored. James> It doesn't need to be ignored, but the order does matter. James> AEAD-* algorithms must appear first in the order list. And James> AEAD-* algos must match cipher and MAC in order as well. It's James> easy to detect, if there is a mismatch between cipher and hmac. What I meant is that IF an AEAD mode cipher is selected THEN the MAC algs negotiation is superfluous and thus to be ignored. It would still be the case that IF the chosen cipher is NOT an AEAD cipher THEN the MAC alg nego would proceed as usual. I see no point whatsoever in trying to force separate cipher mode and MAC negotiation when using AEAD -- it's totally artificial and gains us exactly nothing. Nor should it be possible to use an AEAD cipher and an unrelated MAC -- what would be the point of that? Just because SSHv2 algorithm negotiation made too many assumptions doesn't mean we must beat everything new into the old mold. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 09:40: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 EC05D3A68A5 for ; Wed, 15 Apr 2009 09:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.194, 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 M-koVDjajEc4 for ; Wed, 15 Apr 2009 09:40:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0F44B3A6AE1 for ; Wed, 15 Apr 2009 09:40:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4731063B256; Wed, 15 Apr 2009 16:41:05 +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 0296863B1DB for ; Wed, 15 Apr 2009 16:41:03 +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 n3FGf3QA009395 for ; Wed, 15 Apr 2009 16:41:03 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 n3FGf3hf016304 for ; Wed, 15 Apr 2009 10:41:03 -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 n3FGVcqC011666; Wed, 15 Apr 2009 11:31:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FGVcwO011665; Wed, 15 Apr 2009 11:31:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 11:31:38 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415163138.GR1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151545.LAA00861@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904151545.LAA00861@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 11:43:54AM -0400, der Mouse wrote: > > Without offering a solution to the initial negotiation (all that I > > have seen so far a ugly), I would observe that rekex is far to > > expensive to be a good solution to this problem. > > Agreed. It's just the only solution I see that works within the > existing protocol. (IMO the _right_ answer is to invent/design a > protocol that allows algorithms to be tied together for negotiation.) IMO you're making things too hard. To repeat myself: IF an AEAD mode cipher is selected THEN the MAC algs negotiation is superfluous and thus to be ignored. That's really quite simple. Similarly, IF an AEAD mode cipher is selected THEN the packet length shall be sent unencrypted, with whatever other adjustments need to be made. Though here we can add support for the option that Niels proposed (where the packet lengths are encrypted separately with a separately keyed non-AEAD cipher that's associated with the AEAD cipher). KISS. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 09:42: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 7290A3A6AF7 for ; Wed, 15 Apr 2009 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 oOstR-ixpL6X for ; Wed, 15 Apr 2009 09:42:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5F1743A6C0C for ; Wed, 15 Apr 2009 09:42:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 85C2363B23F; Wed, 15 Apr 2009 16:43:36 +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 DDC0863B1CA for ; Wed, 15 Apr 2009 16:43:34 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 09:38:57 -0700 From: James Blaisdell To: Nicolas Williams , der Mouse CC: "ietf-ssh@NetBSD.org" Date: Wed, 15 Apr 2009 09:43:31 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm96FsKYptwbskFQJCorawdnd8BcgAANnGg Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF41@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151545.LAA00861@Sparkle.Rodents-Montreal.ORG> <20090415163138.GR1500@Sun.COM> In-Reply-To: <20090415163138.GR1500@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I buy your argument, Nico. =20 -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Nicolas Williams Sent: Wednesday, April 15, 2009 9:32 AM To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" On Wed, Apr 15, 2009 at 11:43:54AM -0400, der Mouse wrote: > > Without offering a solution to the initial negotiation (all that I > > have seen so far a ugly), I would observe that rekex is far to > > expensive to be a good solution to this problem. >=20 > Agreed. It's just the only solution I see that works within the > existing protocol. (IMO the _right_ answer is to invent/design a > protocol that allows algorithms to be tied together for negotiation.) IMO you're making things too hard. To repeat myself: IF an AEAD mode cipher is selected THEN the MAC algs negotiation is superfluous and thus to be ignored. That's really quite simple. Similarly, IF an AEAD mode cipher is selected THEN the packet length shall be sent unencrypted, with whatever other adjustments need to be made. Though here we can add support for the option that Niels proposed (where the packet lengths are encrypted separately with a separately keyed non-AEAD cipher that's associated with the AEAD cipher). KISS. Nico --=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 09:46:58 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 8E75E3A6A85 for ; Wed, 15 Apr 2009 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.703 X-Spam-Level: X-Spam-Status: No, score=-5.703 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyERjWOOCQgS for ; Wed, 15 Apr 2009 09:46:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 06A363A6C58 for ; Wed, 15 Apr 2009 09:45:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id ED90B63B24A; Wed, 15 Apr 2009 16:46:49 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id 1616A63B277 for ; Wed, 15 Apr 2009 16:46:45 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FGVhFY026503 for ; Wed, 15 Apr 2009 16:31:43 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 n3FGVg3X007882 for ; Wed, 15 Apr 2009 10:31:42 -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 n3FFxlrw011589; Wed, 15 Apr 2009 10:59:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FFxgeY011588; Wed, 15 Apr 2009 10:59:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 10:59:41 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Tim Polk , ietf-ssh@NetBSD.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415155941.GM1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 10:56:41AM +0200, Niels Möller wrote: > There seem to be two arguments for clear-text lengths: > > 1. "I never liked the encrypted lengths, I think the TLS protocol > design is better". > > 2. It causes additional complexity when implementing AEAD. > > I don't find (1) convincing. I'd prefer not to make design changes of There has been a security vulnerability that resulted from information leaks that take place when the encrypted packet length is decrypted and checked before the MAC is verified. The leak was enormously compounded by sending the decrypted packet length in a DISCONNECT packet, but also by syslog()ing the decrypted packet length as well. And it turns out that it's very difficult to hide the actual packet length. To do it properly you need to send IGNORE messages along with all others, and you need to be very careful how the data is read so that there can't be any TCP window adjustments that reflect the sizes of read() calls. i.e., you don't want to read() the packet length then read() the rest, you want to read as much data as the lesser of max packet size or the amount of data that is in the receive buffers. At the very, very least we ought to document this. > this type at this time, unless there's some really, really good > reason. I'd not be surprised if there are some applications that rely > on the ssh protocol feature that message lengths are encrypted, and > are weakened if we change this. (I'd still appreciate to hear more > details on what security problems others see with encrypted length > fields, though). I can't think of any such applications where random padding and random IGNORE packets wouldn't suffice. And keep in mind that all other Internet protocols that encrypt traffic do not encrypt message lengths. That isn't to say that I'm not concerned about a switch to cleartext packet lengths. There may be unexpected issues that arise from that. > I find (2) extremely unconvincing, since the proposed solutions are > additional levels of negotiation which adds a lot more complexity than > it removes. I strongly dislike having several options for how the > transport layer should work, I do *not* want to have that extra > complexity at this level. One of the options will inevitably be less > well-tested and more buggy than the other. My proposal for negotiation is trivial. Now that we think we know how to properly deal with encrypted packet lengths one could argue that we should continue with that approach. But I would still prefer that we don't for the other reasons that we've given, mostly that encrypted packet lengths with AEAD ciphers may require changing APIs like, for example PKCS#11 (which, now has support for GCM). I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that it does not have any support for encrypted pacaket lengths. And we want to use PKCS#11 in SunSSH, and in fact, we do, though indirectly through the OpenSSL PKCS#11 engine. Forcing us to not be able to use PKCS#11 will severely impact future FIPS compliance projects. > I'd like to propose the following guide-lines for using algorithms in > the AEAD-class with ssh: > > [...] > > 2. The first block of each message is encrypted using a separately > keyed cipher. For AES-GCM, this could be AES in counter mode. For > proper authentication, the clear text for this block is included in > the "associated data" for AEAD, together with the implicit sequence > number, and any other context data that needs authentication. (A > slight elaboration of Damien Miller's idea). > > The choice for the cipher for the first block should of course be > chosen so that it reuses the same primitives as the AEAD-algorithm > that is used. I'm OK with (2) as an option, as the default option. It does add more overhead over AEAD w/ cleartext packet lengths. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 10:25: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 A5A133A6E83 for ; Wed, 15 Apr 2009 10:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 pFrYJzmR+n2L for ; Wed, 15 Apr 2009 10:25:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5CAF43A6E7A for ; Wed, 15 Apr 2009 10:25:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0AB8A63B2A6; Wed, 15 Apr 2009 17:26:22 +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 B875C63B2CD for ; Wed, 15 Apr 2009 17:26:19 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 10:21:42 -0700 From: James Blaisdell To: Nicolas Williams , =?iso-8859-1?Q?Niels_M=F6ller?= CC: Tim Polk , "ietf-ssh@NetBSD.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Date: Wed, 15 Apr 2009 10:26:16 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm96SQmJpBF52+bRJytZJnGWnjJbQABhAyA Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AF5E@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> In-Reply-To: <20090415155941.GM1500@Sun.COM> 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 Precedence: list I am okay with #2 as well. Thanks! > 2. The first block of each message is encrypted using a separately > keyed cipher. For AES-GCM, this could be AES in counter mode. For > proper authentication, the clear text for this block is included in > the "associated data" for AEAD, together with the implicit sequence > number, and any other context data that needs authentication. (A > slight elaboration of Damien Miller's idea). >=20 > The choice for the cipher for the first block should of course be > chosen so that it reuses the same primitives as the AEAD-algorithm > that is used. -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of Nicolas Williams Sent: Wednesday, April 15, 2009 9:00 AM To: Niels M=F6ller Cc: Tim Polk; ietf-ssh@NetBSD.org; Tero Kivinen; Bill Sommerfeld; Chris Lon= vick; ylo@ssh.com; Igoe, Kevin M.; Jerome A. Solinas; Eronen Subject: Re: applying AES-GCM to secure shell: proposed "tweak" On Wed, Apr 15, 2009 at 10:56:41AM +0200, Niels M=F6ller wrote: > There seem to be two arguments for clear-text lengths: >=20 > 1. "I never liked the encrypted lengths, I think the TLS protocol > design is better". >=20 > 2. It causes additional complexity when implementing AEAD. >=20 > I don't find (1) convincing. I'd prefer not to make design changes of There has been a security vulnerability that resulted from information leaks that take place when the encrypted packet length is decrypted and checked before the MAC is verified. The leak was enormously compounded by sending the decrypted packet length in a DISCONNECT packet, but also by syslog()ing the decrypted packet length as well. And it turns out that it's very difficult to hide the actual packet length. To do it properly you need to send IGNORE messages along with all others, and you need to be very careful how the data is read so that there can't be any TCP window adjustments that reflect the sizes of read() calls. i.e., you don't want to read() the packet length then read() the rest, you want to read as much data as the lesser of max packet size or the amount of data that is in the receive buffers. At the very, very least we ought to document this. > this type at this time, unless there's some really, really good > reason. I'd not be surprised if there are some applications that rely > on the ssh protocol feature that message lengths are encrypted, and > are weakened if we change this. (I'd still appreciate to hear more > details on what security problems others see with encrypted length > fields, though). I can't think of any such applications where random padding and random IGNORE packets wouldn't suffice. And keep in mind that all other Internet protocols that encrypt traffic do not encrypt message lengths. That isn't to say that I'm not concerned about a switch to cleartext packet lengths. There may be unexpected issues that arise from that. > I find (2) extremely unconvincing, since the proposed solutions are > additional levels of negotiation which adds a lot more complexity than > it removes. I strongly dislike having several options for how the > transport layer should work, I do *not* want to have that extra > complexity at this level. One of the options will inevitably be less > well-tested and more buggy than the other. My proposal for negotiation is trivial. Now that we think we know how to properly deal with encrypted packet lengths one could argue that we should continue with that approach. But I would still prefer that we don't for the other reasons that we've given, mostly that encrypted packet lengths with AEAD ciphers may require changing APIs like, for example PKCS#11 (which, now has support for GCM). I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that it does not have any support for encrypted pacaket lengths. And we want to use PKCS#11 in SunSSH, and in fact, we do, though indirectly through the OpenSSL PKCS#11 engine. Forcing us to not be able to use PKCS#11 will severely impact future FIPS compliance projects. > I'd like to propose the following guide-lines for using algorithms in > the AEAD-class with ssh: >=20 > [...] >=20 > 2. The first block of each message is encrypted using a separately > keyed cipher. For AES-GCM, this could be AES in counter mode. For > proper authentication, the clear text for this block is included in > the "associated data" for AEAD, together with the implicit sequence > number, and any other context data that needs authentication. (A > slight elaboration of Damien Miller's idea). >=20 > The choice for the cipher for the first block should of course be > chosen so that it reuses the same primitives as the AEAD-algorithm > that is used. I'm OK with (2) as an option, as the default option. It does add more overhead over AEAD w/ cleartext packet lengths. Nico --=20 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 11:05: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 F3EFF28C153 for ; Wed, 15 Apr 2009 11:05:15 -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 xm4dFzI5uiRw for ; Wed, 15 Apr 2009 11:05:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B1FFB28C14F for ; Wed, 15 Apr 2009 11:05:14 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E942E63B2A7; Wed, 15 Apr 2009 18:06:15 +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 C2EE363B143 for ; Wed, 15 Apr 2009 18:06:12 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 9424040038; Wed, 15 Apr 2009 20:05:57 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 89A954004D; Wed, 15 Apr 2009 20:05:57 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 5FD1A40038; Wed, 15 Apr 2009 20:05:57 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FI6A1T002089; Wed, 15 Apr 2009 20:06:10 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FI68Um002088; Wed, 15 Apr 2009 20:06:08 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 20:06:07 +0200 In-Reply-To: <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Wed, 15 Apr 2009 11:10:57 -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: >> (and that all algorithms can be selected independently, except for a >> somewhat vague dependency between key-exchange algorithm and hostkey >> algorithm). > > What's vague about it? Maybe it's not vague, it's long time since I thought about that. Maybe that impression came from the fact that there's no widely supported key exchange method that needs a public key encryption, so it's rarely making a difference. > Or some other set of cross-linked magic dependencies end up requiring > something effectively similar. If we do this, it won't be the last > such piece of negotiation magic, I'm sure of that. Can you substantiate that feeling? We have one magic interdependency already (keyexchange/hostkey), introduced in the original spec some ten years ago. Now we're discussing another one, from the introduction of algorithms with "simultaneous" encryption and authentication. I doubt we'll have to do things like that very often. New cryptographic primitives, useful for this kind of protocol, don't appear very often. Do you see any other potential magic dependencies down the road? And if there are any conflicts in the future, say, with the introduction of foo-mac, which we can't handle in any better way, we could handle it by specifying that an implementation MUST NOT advertise both the deprecated aead algorithms and foo-mac, and maybe also deprecate the aead stuff we're discussing now. But I honestly don't find that scenario very likely. So what I'm saying, is that I understand that you care to maintain a clean and beautyful spec. My view is that I don't see much practical or aestetical problems arising from this particular "magic" dependency, which I think is similar in spirit to the key exchange/hostkey dependency, and that the alternatives are worse because they bring more complexity and hence more bugs. I'm strongly against adding new general option or negotiation frameworks just to support aead. That's simply not worth the effort. If we can't come up with a reasonable way to "shoehorn" it into the current algorithm selection precedures, I'd prefer to say "Sorry, aead-style algorithms were not envisioned when the ssh protocols were designed. It can't be supported. Maybe it'll be supported in ssh protocol version 3 in the very distant future.". /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 11:23: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 C179428C189 for ; Wed, 15 Apr 2009 11:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_05=-1.11, 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 T8iWHmnA1z4l for ; Wed, 15 Apr 2009 11:23:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id F3F4228C186 for ; Wed, 15 Apr 2009 11:23:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C10163B2DC; Wed, 15 Apr 2009 18:24: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 56EF463B143 for ; Wed, 15 Apr 2009 18:24:05 +0000 (UTC) Received: from Atlantic ([69.57.253.76]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Wed, 15 Apr 2009 14:24:44 -0400 Message-ID: <371B5151902844ABB1B08F333F2F9425@Atlantic> From: "denis bider \(Bitvise\)" To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov><200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Date: Wed, 15 Apr 2009 14:24:21 -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.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > If ssh starts going down that road, another dozen or so "special cases" > later it'll be a horrible mess of magic interdependencies, with > determining whether negotiation _can_ succeed bordering on NP-hard. SSH is already down that road. GSSAPI key exchange requires ignoring the negotiated host key algorithm. I think you're exaggerating the problem. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 11:41:06 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 EEBAA3A6BA6 for ; Wed, 15 Apr 2009 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwOqhNwOQoqX for ; Wed, 15 Apr 2009 11:41:06 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BAF6E3A68D5 for ; Wed, 15 Apr 2009 11:41:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4DC7163B1A6; Wed, 15 Apr 2009 18:42:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id B05BD63B1CA for ; Wed, 15 Apr 2009 18:42:02 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FIg2q4004238 for ; Wed, 15 Apr 2009 18:42:02 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 n3FIg1AX056271 for ; Wed, 15 Apr 2009 12:42:02 -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 n3FIP4Le011748; Wed, 15 Apr 2009 13:25:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FIP4k9011747; Wed, 15 Apr 2009 13:25:04 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 13:25:04 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415182503.GV1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 08:06:07PM +0200, Niels Möller wrote: > I'm strongly against adding new general option or negotiation > frameworks just to support aead. That's simply not worth the effort. +1 For me that goes for Mouse's and Jeff's proposals both. > If we can't come up with a reasonable way to "shoehorn" it into the > current algorithm selection precedures, I'd prefer to say "Sorry, > aead-style algorithms were not envisioned when the ssh protocols were > designed. It can't be supported. Maybe it'll be supported in ssh > protocol version 3 in the very distant future.". I agree, but it won't come to that. The reason is that we _can_ shoehorn AEAD into SSHv2. We already have a number of things shoehorned into the SSHv2 kex, such as: - GSS-API (which is not like the host authentication algorithms originally envisioned) - not only is there the whole GSS-API token exchange and the MIC sent by the server to authenticate the key exchange, but also - there's the need for a "null" or "none" host key alg to support re-keys without re-authentication, but only re-keys. - negotiation of compression only post-authentication (a very useful and awesome OpenSSH extension) AEAD is trivial by comparison to the GSS-API: the MAC algs are irrelevant when AEAD ciphers are negotiated, for the obvious reason that the MAC is subsumed into the cipher mode. There's no need to agonize over "none". What else might we shoehorn into kex? Well: - Key transport instead of key agreement. This one right and truly screws with the idea of separate key exchange and host auth algs. So what? It can still be shoehorned in in exactly the same way as AEAD: if you pick a key transport key exchange alg then the host auth alg negotiation becomes irrelevant. (Oh, I suppose one could sign a key transport with a separate signature key, thus allowing one to separate key exchange and host auth even in the key transport case, but that just seems silly as it adds a public key op that should be unnecessary.) - Retriable initial kex, for example (this is so that GSS-API auth failure need not lead to the connection being closed). For this I'd use the reserved unsigned 32-bit int in the KEXINIT as a flags field -- if both the client and the server have the flag set for re-triable kex then GSS-API failure should not lead to connection closure. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 11: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 C23ED3A6B24 for ; Wed, 15 Apr 2009 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.050, 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 YimaGBFcW39i for ; Wed, 15 Apr 2009 11:53:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BD6663A6B07 for ; Wed, 15 Apr 2009 11:53:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 96F2763B2CF; Wed, 15 Apr 2009 18:54:29 +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 07FCB63B18D for ; Wed, 15 Apr 2009 18:54:26 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2BBAA40038; Wed, 15 Apr 2009 20:54:10 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 1F5354004D; Wed, 15 Apr 2009 20:54:10 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 3A30A40038; Wed, 15 Apr 2009 20:54:09 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FIsMNa003792; Wed, 15 Apr 2009 20:54:22 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FIsMMI003789; Wed, 15 Apr 2009 20:54:22 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 20:54:21 +0200 In-Reply-To: <20090415155941.GM1500@Sun.COM> (Nicolas Williams's message of "Wed, 15 Apr 2009 10:59:41 -0500") 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 Nicolas Williams writes: > There has been a security vulnerability that resulted from information > leaks that take place when the encrypted packet length is decrypted and > checked before the MAC is verified. The leak was enormously compounded > by sending the decrypted packet length in a DISCONNECT packet, but also > by syslog()ing the decrypted packet length as well. Thanks. Do you have a pointer to more details? > I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that > it does not have any support for encrypted pacaket lengths. I think it would be valuable if you could check that. Other APIs and toolkits mentioned in the discussion seem to support it. The specification, http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf, says the following as the first item in the feature list (page 2): * The GCM functions are "online" in the sense that the lengths of the confidential data and the additional, non-confidential data are not required in advance; instead, the lengths can be calculated as the data arrives and is processed. I'd expect that implementations allow processing the first block as soon it it has arrived. (Yes, I realize the above sentence is not normative in any way, and it might be interpreted differently, but at least I think it's clear that block-by-block (or even byte-by-byte) operations are considered reasonable). (And the last time convenient use of some existing programming API had a clear and visible impact on the design of the ssh protocols, we got the "dss_signature_blob" (RFC 4253, section 6.6)...). Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 12:22:32 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 683EF3A6F1E for ; Wed, 15 Apr 2009 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.192, 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 DS13N6NShIPd for ; Wed, 15 Apr 2009 12:22:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D3A723A68D5 for ; Wed, 15 Apr 2009 12:22:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B280C63B143; Wed, 15 Apr 2009 19:23:29 +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 D42C963B2BD for ; Wed, 15 Apr 2009 19:23:27 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FJNRvn012293 for ; Wed, 15 Apr 2009 19:23:27 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 n3FJNQFg010131 for ; Wed, 15 Apr 2009 13:23:26 -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 n3FIh47L011804; Wed, 15 Apr 2009 13:43:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FIfIT6011803; Wed, 15 Apr 2009 13:41:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 13:41:18 -0500 From: Nicolas Williams To: James Blaisdell Cc: Niels =?iso-8859-1?Q?M=F6ller?= , Tim Polk , "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415184118.GW1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 05:51:24AM -0700, James Blaisdell wrote: > I can live with cleartext length field or encrypted length field. I > have implemented AES-GCM as the draft stands now, so I know it's > technically possible. It has been suggested that some AES-GCM > implementations must process the message as a single block of data --- > a black box. I don't know what hardware offload (proprietary?) that > is unable to process AES-GCM in a chunk manner; Cavium can process in > chunks. I suppose at some point in the future an AEAD-* method will > not be able to process the message in chunks, but this draft is for > AEAD-AES-GCM. Are we trying to future proof something that may never > happen? Even so, I would imagine it could dealt with at that time --- > there will be an inconsistency now or future. It is entirely reasonable to construct AEAD APIs that require that the caller provide the correct length up front. Were it not for this particular document that's exactly how I'd do it. IN FACT, that's EXACTLY how PKCS#11 handles AEAD. See: http://mirror.switch.ch/ftp/doc/standard/pkcs/pkcs-11/v2-30/pkcs-11v2-20a5d1.pdf "Set the message/data length ulDataLen in the parameter block. This length should not include the length of the MAC that is appended to the cipher text." > I do agree sending the length field in the clear will cause some > headaches at a lowest level, since a new in/out method will need to be > written and tested. However, I don't see the issues around NEWKEY > some have suggested, but perhaps that implementation specific. The > encrypted length field has been a pain in the past, especially for > async implementations like mine, but I have lived with it fine for > last few years. Encrypted packet length will cause more headaches if it means changing AEAD APIs. If we really, really want encrypted packet lengths then let's use Niels' proposal of using a separate and separately keyed non-AEAD cipher to encrypt the packet length and then use the AEAD cipher to encrypt the rest of the packet. (Niels' proposal has to involve padding the packet length if the non-AEAD cipher used to encrypt the packet length is not a counter mode or stream cipher.) > The only issue I have any energy around are suggestions for fallback > approaches or no-MAC; similar approaches have been suggested for > SSH-ECDSA. These approaches create a great deal of work and break the > current protocol model. Agreed, but no such suggestions are on the table. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 12:52: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 75E6F3A6C1A for ; Wed, 15 Apr 2009 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 loh91Xn9mUPH for ; Wed, 15 Apr 2009 12:52:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 0805D3A6F1F for ; Wed, 15 Apr 2009 12:52:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DDB7163B2E6; Wed, 15 Apr 2009 19:53:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 3238163B2AB for ; Wed, 15 Apr 2009 19:53:00 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (host-69-95-83-226.pit.choiceone.net [69.95.83.226]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3FJqkiM010200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:52:52 -0400 (EDT) Date: Wed, 15 Apr 2009 15:52:46 -0400 From: Jeffrey Hutzelman To: =?UTF-8?Q?Niels_M=C3=B6ller?= , der Mouse cc: ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 15, 2009 01:33:25 PM +0200 Niels M=C3=B6ller=20 wrote: > Analogously, if we specify a keyexchange algorithm with integrated > server authentication (say, using SRP or something like that for the > key exchange), we can say that the hostkey algorithm is moot and > ignored. Actually, we very nearly do this; see RFC4462. What saves us with keyex=20 and host key algorithms is that the base spec defines several properties of = host key algorithms (can sign, can encrypt), and keyex methods specify=20 which ones they depend on; the host key algorithm chosen is the first one=20 that meets the requirements of the selected keyex algorithm. This lets=20 RFC4462 specify that the GSS keyex methods depend on neither signing nor=20 encrypting. Since the null host key algorithm (also defined in RFC4462)=20 provides neither of those capabilities, we can list it (last). This means=20 we can negotiate (DH,RSA) or (GSS-KRB5,NULL) without having to worry about=20 getting (DH,NULL). However it also means we will get (GSS-KRB5,RSA) if=20 both sides advertise both GSS-KRB5 and RSA. That's actually desirable for=20 the GSS keyex families. We could do something analogous for encryption and host key algorithms, but = I don't think it would get you what you want; in particular, it leads to=20 negotiating a superfluous MAC. What I'd suggest instead is defining a unique MAC alogrithm for each AEAD=20 encryption algorithm, which has the same effects as null but is usable=20 _only_ when the corresponding encryption algorithm is selected. This is a=20 simple and straightforward modification to the negotiation rules which=20 allows the new MAC algorithms to be listed _first_ to ensure you don't do=20 extra MAC's when an AEAD encryption algorithm is selected, but without=20 adversely affecting the MAC negotiation when an AEAD encryption algorithm=20 is _not_ selected -- even when one of the peers is not AEAD aware. > I also find it brittle to renegotiate with a subset of the previous > algorithms, in particular when you exclude one of the *selected* > algorithms. Imagine that both sides attempt renegotiation, and that > they do it slightly differently. Then the connection may fall apart. > And if you want to avoid such problems by specifying in more detail > what the policy behind the renegotiation should be, then I'd much > prefer to specify *explicitly* what it is you want to achieve, e.g., > that no mac should be used together with AEAD, and then implement that > policy at both ends with no extra negotiation. Agree. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 12:52:21 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 1449B3A6F36 for ; Wed, 15 Apr 2009 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 B3z3BxnICOMu for ; Wed, 15 Apr 2009 12:52:12 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BD8A33A6F1F for ; Wed, 15 Apr 2009 12:52:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 11D8263B1D3; Wed, 15 Apr 2009 19:53:21 +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 3104463B149 for ; Wed, 15 Apr 2009 19:53:18 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 12:48:42 -0700 From: James Blaisdell To: Nicolas Williams CC: =?iso-8859-1?Q?Niels_M=F6ller?= , Tim Polk , "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Date: Wed, 15 Apr 2009 12:53:16 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm9/ffNljFnHq+sSk6nTiD3os9a+wABYuxA Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AFA9@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> <20090415184118.GW1500@Sun.COM> In-Reply-To: <20090415184118.GW1500@Sun.COM> 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 Precedence: list Woah... I agreed with you, that option #2 is the best approach. Did you n= ot see 2 hours ago. As I said, it working for me now --- yes, I've impleme= nted it. I am happy to change it. Thanks! -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Wednesday, April 15, 2009 11:41 AM To: James Blaisdell Cc: Niels M=F6ller; Tim Polk; ietf-ssh@netbsd.org; Tero Kivinen; Bill Somme= rfeld; Chris Lonvick; ylo@ssh.com; Igoe, Kevin M.; Jerome A. Solinas; Eronen Subject: Re: applying AES-GCM to secure shell: proposed "tweak" On Wed, Apr 15, 2009 at 05:51:24AM -0700, James Blaisdell wrote: > I can live with cleartext length field or encrypted length field. I > have implemented AES-GCM as the draft stands now, so I know it's > technically possible. It has been suggested that some AES-GCM > implementations must process the message as a single block of data --- > a black box. I don't know what hardware offload (proprietary?) that > is unable to process AES-GCM in a chunk manner; Cavium can process in > chunks. I suppose at some point in the future an AEAD-* method will > not be able to process the message in chunks, but this draft is for > AEAD-AES-GCM. Are we trying to future proof something that may never > happen? Even so, I would imagine it could dealt with at that time --- > there will be an inconsistency now or future. =20 It is entirely reasonable to construct AEAD APIs that require that the caller provide the correct length up front. Were it not for this particular document that's exactly how I'd do it. IN FACT, that's EXACTLY how PKCS#11 handles AEAD. See: http://mirror.switch.ch/ftp/doc/standard/pkcs/pkcs-11/v2-30/pkcs-11v2-20a5d= 1.pdf "Set the message/data length ulDataLen in the parameter block. This length should not include the length of the MAC that is appended to the cipher text." > I do agree sending the length field in the clear will cause some > headaches at a lowest level, since a new in/out method will need to be > written and tested. However, I don't see the issues around NEWKEY > some have suggested, but perhaps that implementation specific. The > encrypted length field has been a pain in the past, especially for > async implementations like mine, but I have lived with it fine for > last few years. =20 Encrypted packet length will cause more headaches if it means changing AEAD APIs. If we really, really want encrypted packet lengths then let's use Niels' proposal of using a separate and separately keyed non-AEAD cipher to encrypt the packet length and then use the AEAD cipher to encrypt the rest of the packet. (Niels' proposal has to involve padding the packet length if the non-AEAD cipher used to encrypt the packet length is not a counter mode or stream cipher.) > The only issue I have any energy around are suggestions for fallback > approaches or no-MAC; similar approaches have been suggested for > SSH-ECDSA. These approaches create a great deal of work and break the > current protocol model. =20 Agreed, but no such suggestions are on the table. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 13:01:05 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 AE8083A6E77 for ; Wed, 15 Apr 2009 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.848, 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 W-eIXfsR+LTR for ; Wed, 15 Apr 2009 13:01:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id EBEF828C1E9 for ; Wed, 15 Apr 2009 13:00:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1525E63B1CF; Wed, 15 Apr 2009 20:01:55 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 04A5663B2F8 for ; Wed, 15 Apr 2009 20:01:52 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (host-69-95-83-226.pit.choiceone.net [69.95.83.226]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3FK1kDB010581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 16:01:48 -0400 (EDT) Date: Wed, 15 Apr 2009 16:01:46 -0400 From: Jeffrey Hutzelman To: "denis bider (Bitvise)" , ietf-ssh@NetBSD.org cc: jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <356810043BE14A2ED687C4FC@atlantis.pc.cs.cmu.edu> In-Reply-To: <371B5151902844ABB1B08F333F2F9425@Atlantic> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <371B5151902844ABB1B08F333F2F9425@Atlantic> 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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 15, 2009 02:24:21 PM -0400 "denis bider (Bitvise)" wrote: >> If ssh starts going down that road, another dozen or so "special cases" >> later it'll be a horrible mess of magic interdependencies, with >> determining whether negotiation _can_ succeed bordering on NP-hard. > > SSH is already down that road. GSSAPI key exchange requires ignoring the > negotiated host key algorithm. No, it most certainly does not. GSS keyex depends on neither public key signature nor encryption, and so can be used with host key algorithms which provide neither, such as "null". It does not _require_ use of such an algorithm; it works with any host key algorithm and in fact has the side effect of authenticating whatever host key is used. It certainly does not require ignoring the results of host key algorithm negotiation and using some other host key instead. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 13:09: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 EBD2E3A6C5B for ; Wed, 15 Apr 2009 13:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.284 X-Spam-Level: X-Spam-Status: No, score=-9.284 tagged_above=-999 required=5 tests=[AWL=0.704, 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 KL1G0IP-OU6l for ; Wed, 15 Apr 2009 13:09:30 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2EF843A6BF8 for ; Wed, 15 Apr 2009 13:09:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A69C63B364; Wed, 15 Apr 2009 20:10:38 +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 5ED6263B2D1 for ; Wed, 15 Apr 2009 20:10:36 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA02715; Wed, 15 Apr 2009 16:10:35 -0400 (EDT) From: der Mouse Message-Id: <200904152010.QAA02715@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, 15 Apr 2009 16:09:49 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > It doesn't need to be ignored, but the order does matter. AEAD-* > algorithms must appear first in the order list. That's completely unextendable; what happens when another algorithm is added that also "must appear first"? /~\ 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 Apr 15 13:19:25 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 99A983A6922 for ; Wed, 15 Apr 2009 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=0.678, 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 ZH1f8nMIi9Ma for ; Wed, 15 Apr 2009 13:19:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B4A4E3A6A17 for ; Wed, 15 Apr 2009 13:19:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 599AB63B15F; Wed, 15 Apr 2009 20:20:31 +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 06AF963B2DF for ; Wed, 15 Apr 2009 20:20:29 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA02788; Wed, 15 Apr 2009 16:20:28 -0400 (EDT) From: der Mouse Message-Id: <200904152020.QAA02788@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, 15 Apr 2009 16:10:58 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415160759.GN1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> <20090415160759.GN1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Just because SSHv2 algorithm negotiation made too many assumptions > doesn't mean we must beat everything new into the old mold. Of course not. But, conversely, you shouldn't be beating everything old into compatability with the new, either, and that's what looks to be happening here: people seem determined to find _some_ way to marry AEAD and SSHv2. I don't see why, given how poor a match they are. /~\ 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 Apr 15 13:27:22 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 B49883A6F37 for ; Wed, 15 Apr 2009 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.334 X-Spam-Level: X-Spam-Status: No, score=-9.334 tagged_above=-999 required=5 tests=[AWL=0.654, 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 b7RORw3i3+GF for ; Wed, 15 Apr 2009 13:27:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D0A2F3A6E8E for ; Wed, 15 Apr 2009 13:27:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 855DE63B228; Wed, 15 Apr 2009 20:28:29 +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 79C2F63B271 for ; Wed, 15 Apr 2009 20:28:27 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA02868; Wed, 15 Apr 2009 16:28:26 -0400 (EDT) From: der Mouse Message-Id: <200904152028.QAA02868@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, 15 Apr 2009 16:20:46 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415155941.GM1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > There has been a security vulnerability that resulted from > information leaks that take place when the encrypted packet length is > decrypted and checked before the MAC is verified. Which actually is mostly unavoidable, since the MAC can't be even _located_ until the packet length is known. > The leak was enormously compounded by sending the decrypted packet > length in a DISCONNECT packet, !! It's hardly the fault of the protocol if implementations gratuitously leak cribs for attacking the crypto! Some information leakage is unavoidable; if nothing else, the placement of error detection by the receiver can act as an oracle for whether the decrypted length falls into certain ranges. But that's a far cry from blatantly leaking 32 of the cleartext bits for attacher-chosen ciphertext. (Though, even then, it's just a flavour of chosen-ciphertext attack, and a relatively expensive one - got a reference to the weakness in question? Even though I'm just a dilettante as a cryptographer, I'd like to have a look for myself.) /~\ 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 Apr 15 13:37: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 58BA63A6F48 for ; Wed, 15 Apr 2009 13:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] 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 DW+To8CITbI8 for ; Wed, 15 Apr 2009 13:37:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4B75628C1F1 for ; Wed, 15 Apr 2009 13:37:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 707D963B385; Wed, 15 Apr 2009 20:38:32 +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 7C1A763B2DF for ; Wed, 15 Apr 2009 20:38:29 +0000 (UTC) Received: from yugi.mocana.local ([192.168.3.216]) by yugi.mocana.local ([192.168.3.216]) with mapi; Wed, 15 Apr 2009 13:33:52 -0700 From: James Blaisdell To: der Mouse , "ietf-ssh@NetBSD.org" Date: Wed, 15 Apr 2009 13:38:26 -0700 Subject: RE: applying AES-GCM to secure shell: proposed "tweak" Thread-Topic: applying AES-GCM to secure shell: proposed "tweak" Thread-Index: Acm+BZ0RyZyNaaK5RTuNcIXn00bnnQAAufjA Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A8551AFB8@yugi.mocana.local> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hey Mouse, The discussions have been fiery goodness. I think a good conclusions are b= eing reached. =20 You are correct --- the order will likely be a pain, if there are higher pr= io algos that are not AEAD --- I rationalized the solution as I coded it up= (my mistake). I think having AEAD-* algos ignore hmac algos is likely a g= ood thing. =20 I think AES-CTR for the length field is a good least painful approach (opti= on #2); details missing what key to use. I am certain PKCS#11 will prove t= o be excruciatingly slow to implement 4-byte AES-CTR jobs, which then means= software version needs to be FIPS --- sorry. For makekey(), maybe same le= tter e.g. "d", but twice for sub algos? I'd hate for us to pick just an in= cremental letter since that will not be future proof (collisions). =20 Would AES-CTR be used as a stream cipher, so four lengths would be encipher= /decipher per count, or not? =20 There are still some open issues even with these alternative approaches. I= am going shut up now. =20 Thanks, James -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behal= f Of der Mouse Sent: Wednesday, April 15, 2009 1:10 PM To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" > It doesn't need to be ignored, but the order does matter. AEAD-* > algorithms must appear first in the order list. That's completely unextendable; what happens when another algorithm is added that also "must appear first"? /~\ 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 Apr 15 13:42:59 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 BB0023A6A8C for ; Wed, 15 Apr 2009 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.192, 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 ghLq0WmpE024 for ; Wed, 15 Apr 2009 13:42:59 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1693D28C184 for ; Wed, 15 Apr 2009 13:42:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 049C963B3D4; Wed, 15 Apr 2009 20:44:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id CF01F63B388 for ; Wed, 15 Apr 2009 20:43:55 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FKhsw4009107 for ; Wed, 15 Apr 2009 20:43:55 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 n3FKhswe017997 for ; Wed, 15 Apr 2009 14:43:54 -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 n3FKYUVq011853; Wed, 15 Apr 2009 15:34:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FKYQen011852; Wed, 15 Apr 2009 15:34:26 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 15:34:26 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415203426.GZ1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 04:09:49PM -0400, der Mouse wrote: > > It doesn't need to be ignored, but the order does matter. AEAD-* > > algorithms must appear first in the order list. > > That's completely unextendable; what happens when another algorithm is > added that also "must appear first"? James is wrong. There's no need to put AEAD ciphers first, unless, of course, one prefers them. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 13:47:47 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 300573A6F3D for ; Wed, 15 Apr 2009 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.191, 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 9c5DwDpiOJBo for ; Wed, 15 Apr 2009 13:47:46 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3534F3A6F7D for ; Wed, 15 Apr 2009 13:47:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8480763B39A; Wed, 15 Apr 2009 20:48:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 8755E63B382 for ; Wed, 15 Apr 2009 20:48:10 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FKm9kK022791 for ; Wed, 15 Apr 2009 20:48: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 n3FKm9pC010387 for ; Wed, 15 Apr 2009 14:48: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 n3FKcjSG011859; Wed, 15 Apr 2009 15:38:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FKcjPm011858; Wed, 15 Apr 2009 15:38:45 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 15:38:45 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415203845.GA1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <200904152028.QAA02868@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904152028.QAA02868@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 04:20:46PM -0400, der Mouse wrote: > > There has been a security vulnerability that resulted from > > information leaks that take place when the encrypted packet length is > > decrypted and checked before the MAC is verified. > > Which actually is mostly unavoidable, since the MAC can't be even > _located_ until the packet length is known. > > > The leak was enormously compounded by sending the decrypted packet > > length in a DISCONNECT packet, > > !! It's hardly the fault of the protocol if implementations > gratuitously leak cribs for attacking the crypto! Even without the DISCONNECT and syslogging you still leak quite a bit IFF the packet length decodes to something less than max packet. Yes, it's unlikely for an active attacker to cause that, since max packet will usually be on the order of 2^16 but the truly max packet length is on the order of 2^32, but surely you see the point. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 13:49:14 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 714B63A679F for ; Wed, 15 Apr 2009 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.706 X-Spam-Level: X-Spam-Status: No, score=-5.706 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB2OjbHiK2ma for ; Wed, 15 Apr 2009 13:49:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4D4F43A6B21 for ; Wed, 15 Apr 2009 13:49:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2911263B37C; Wed, 15 Apr 2009 20:50:22 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id DBF6863B23C for ; Wed, 15 Apr 2009 20:50:19 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FKoJTo005807 for ; Wed, 15 Apr 2009 20:50:19 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 n3FKoJKj012121 for ; Wed, 15 Apr 2009 14:50:19 -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 n3FKXPJw011847; Wed, 15 Apr 2009 15:33:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FKXP7d011846; Wed, 15 Apr 2009 15:33:25 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 15:33:25 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415203325.GY1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 08:54:21PM +0200, Niels Möller wrote: > Nicolas Williams writes: > > > There has been a security vulnerability that resulted from information > > leaks that take place when the encrypted packet length is decrypted and > > checked before the MAC is verified. The leak was enormously compounded > > by sending the decrypted packet length in a DISCONNECT packet, but also > > by syslog()ing the decrypted packet length as well. > > Thanks. Do you have a pointer to more details? http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt > > I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that > > it does not have any support for encrypted pacaket lengths. > > I think it would be valuable if you could check that. Other APIs and toolkits I did, and I posted on that a few hours ago. And lo and behold, PKCS#11 does indeed require that the length be provided by the application at decrypt time -- or at least that's my interpretation of the draft, but I'll re-read it in case you're correct that it's online, that one could call C_DecryptUpdate() once to get the length (and padding, ...) then again to get the rest. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:02: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 9A25F3A6F2E for ; Wed, 15 Apr 2009 14:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.043, 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 lUTCT+pFdKTu for ; Wed, 15 Apr 2009 14:02:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B117828C27D for ; Wed, 15 Apr 2009 14:00:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 97DAD63B241; Wed, 15 Apr 2009 21:02:06 +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 5EE6263B2AB for ; Wed, 15 Apr 2009 21:02:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AF24840042; Wed, 15 Apr 2009 23:01:45 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id A4D2040046; Wed, 15 Apr 2009 23:01:45 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 8190140042; Wed, 15 Apr 2009 23:01:45 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FL1wo5008360; Wed, 15 Apr 2009 23:01:58 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FL1wZc008359; Wed, 15 Apr 2009 23:01:58 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 23:01:58 +0200 In-Reply-To: <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 15 Apr 2009 15:52:46 -0400") 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 Jeffrey Hutzelman writes: > What I'd suggest instead is defining a unique MAC alogrithm for each > AEAD encryption algorithm, which has the same effects as null but is > usable _only_ when the corresponding encryption algorithm is selected. I'm not sure I follow precisely what you mean, but I think the important structural change is that we say that should apply algorithm selection to the encryption algorithm first, before selecting the mac algorithm. Then the result of the selection of the encryption algorithm may trigger special behaviour when it comes to the MAC algorithm. The naive rule "If an AEAD-algorithm is selected for encryption, no other MAC is used, and it doesn't matter whatsoever what's on the MAC algorithm lists" is simple and I think it should work, although I'm open to other variations. Implementations not supporting AEAD need of course not know or care about this rule. A party that advertises only AEAD-algorithms for encryption can safely list "none" as the only MAC algorithm (IIRC, it's not allowed to send an empty list, and any value, not just "none", will work just as well), negotiation with a party not supporting AEAD will then fail in an orderly manner. A party that lists AEAD and some non-AEAD encryption algorithm, will list the MACs that it's willing to use together with non-AEAD encryption. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:05:07 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 D3A8728C270 for ; Wed, 15 Apr 2009 14:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.037, 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 X3+GX34ZZQ9l for ; Wed, 15 Apr 2009 14:05:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id DDB3F3A6F42 for ; Wed, 15 Apr 2009 14:05:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0452463B3C1; Wed, 15 Apr 2009 21:06:04 +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 D4B5563B2AB for ; Wed, 15 Apr 2009 21:05:57 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 19C3340011; Wed, 15 Apr 2009 23:05:40 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 0D55F4002E; Wed, 15 Apr 2009 23:05:40 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id EEA4940011; Wed, 15 Apr 2009 23:05:39 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FL5rlL008481; Wed, 15 Apr 2009 23:05:53 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FL5rvu008480; Wed, 15 Apr 2009 23:05:53 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 23:05:52 +0200 In-Reply-To: <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> (der Mouse's message of "Wed, 15 Apr 2009 16:09:49 -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: >> It doesn't need to be ignored, but the order does matter. AEAD-* >> algorithms must appear first in the order list. > > That's completely unextendable; what happens when another algorithm is > added that also "must appear first"? Agreed. That's not acceptable. And besides that, it should be possible to express old-fashioned preferences, like "I really like triple-DES, but if you don't support it, I'll go with AEAD as a fallback". Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:09: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 BA7423A6F5B for ; Wed, 15 Apr 2009 14:09:08 -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=[AWL=0.000, 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 OzFUAaaYps0H for ; Wed, 15 Apr 2009 14:09:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3A7FB3A6C3B for ; Wed, 15 Apr 2009 14:09:06 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 03FDF63B140; Wed, 15 Apr 2009 21:10:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9F29E63B172 for ; Wed, 15 Apr 2009 21:10:10 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 3D23AC4AFF; Thu, 16 Apr 2009 07:10:08 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 79D6DC4AAF; Thu, 16 Apr 2009 07:10:02 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 8591AA4F54; Thu, 16 Apr 2009 07:10:01 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 836CAA4F51; Thu, 16 Apr 2009 07:10:01 +1000 (EST) Date: Thu, 16 Apr 2009 07:10:01 +1000 (EST) From: Damien Miller To: James Blaisdell cc: Nicolas Williams , der Mouse , "ietf-ssh@NetBSD.org" Subject: RE: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, James Blaisdell wrote: > It doesn't need to be ignored, but the order does matter. AEAD-* > algorithms must appear first in the order list. And AEAD-* algos must > match cipher and MAC in order as well. It's easy to detect, if there > is a mismatch between cipher and hmac. -1 That has the nasty side effect of specifying Cipher/MAC policy to server operators. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:14: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 664333A6C3B for ; Wed, 15 Apr 2009 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.033, 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 GwFecfumdACa for ; Wed, 15 Apr 2009 14:14:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 66AF028C26F for ; Wed, 15 Apr 2009 14:14:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 644BB63B184; Wed, 15 Apr 2009 21:15:59 +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 4866163B119 for ; Wed, 15 Apr 2009 21:15:56 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1A42D40011; Wed, 15 Apr 2009 23:15:40 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 0DEEE4002E; Wed, 15 Apr 2009 23:15:40 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id D4D4340011; Wed, 15 Apr 2009 23:15:39 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3FLFroE008827; Wed, 15 Apr 2009 23:15:53 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3FLFnoG008824; Wed, 15 Apr 2009 23:15:49 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: James Blaisdell , Tim Polk , "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> <20090415184118.GW1500@Sun.COM> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Wed, 15 Apr 2009 23:15:48 +0200 In-Reply-To: <20090415184118.GW1500@Sun.COM> (Nicolas Williams's message of "Wed, 15 Apr 2009 13:41:18 -0500") 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 Nicolas Williams writes: > Encrypted packet length will cause more headaches if it means changing > AEAD APIs. If we really, really want encrypted packet lengths then > let's use Niels' proposal of using a separate and separately keyed > non-AEAD cipher to encrypt the packet length and then use the AEAD > cipher to encrypt the rest of the packet. (Niels' proposal has to > involve padding the packet length if the non-AEAD cipher used to encrypt > the packet length is not a counter mode or stream cipher.) Actually, I'm suggested that we encrypt the first *block*, not just the length field, with an independent cipher. The full block is then authenticated as additional data to AEAD. In the case of AES-GCM, there's a natural block size, and a reasonable choice for this cipher is AES-CTR. This way, there's nothing special to the padding. What's actually done to the data is very similar to what you'd do if you applied AES-GCM to the entire message including length field, and extracted length field first when decrypting. (It would be nice in some ways, but less general, if the details could be defined so that the result is *identical*). Encrypting only the length field (or length + padding) would cause more complexity and more overhead, I think. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:19:32 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 A4C3B28C271 for ; Wed, 15 Apr 2009 14:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.190, 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 59JIFOWqd9O1 for ; Wed, 15 Apr 2009 14:19:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7614428C26F for ; Wed, 15 Apr 2009 14:19:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9FDE963B17C; Wed, 15 Apr 2009 21:20:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id 96E0163B165 for ; Wed, 15 Apr 2009 21:20:33 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FLKXb4019139 for ; Wed, 15 Apr 2009 21:20:33 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 n3FLKWZb044687 for ; Wed, 15 Apr 2009 15:20:32 -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 n3FLB8vH011907; Wed, 15 Apr 2009 16:11:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FLB8IQ011906; Wed, 15 Apr 2009 16:11:08 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:11:08 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415211108.GH1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <200904152028.QAA02868@Sparkle.Rodents-Montreal.ORG> <20090415203845.GA1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090415203845.GA1500@Sun.COM> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 03:38:45PM -0500, Nicolas Williams wrote: > On Wed, Apr 15, 2009 at 04:20:46PM -0400, der Mouse wrote: > > > There has been a security vulnerability that resulted from > > > information leaks that take place when the encrypted packet length is > > > decrypted and checked before the MAC is verified. > > > > Which actually is mostly unavoidable, since the MAC can't be even > > _located_ until the packet length is known. > > > > > The leak was enormously compounded by sending the decrypted packet > > > length in a DISCONNECT packet, > > > > !! It's hardly the fault of the protocol if implementations > > gratuitously leak cribs for attacking the crypto! > > Even without the DISCONNECT and syslogging you still leak quite a bit > IFF the packet length decodes to something less than max packet. Yes, > it's unlikely for an active attacker to cause that, since max packet > will usually be on the order of 2^16 but the truly max packet length is > on the order of 2^32, but surely you see the point. The reason you leak if the packet length decodes to something less than max packet is this: The attacker can modify what he thinks is encrypted ciphertext and hope it decrypts to a value less than max packet, then he can send garbage one block at a time until the peer responds by closing the connection when the MAC fails to validate. The attacker then knows the decrupted packet size to within one block size. If max packet size is much smaller than the max possible packet length then most of the time all that's leaked is that the decrypted packet size is larger than the negotiated max packet length and so this attack is not worthwhile. With HPN in the picture I'm not sure that that will be the case, though one expects no active attackers in HPN cases, but still. With a cleartext packet length you don't have any of these problems. Instead you get the normal traffic analysis problems, such as the ability to recognize echo-off password prompts and count any one-character packets and thus determine packet length. However, these problems can be addressed without cryptography. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:21:54 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 6E0823A6F3D for ; Wed, 15 Apr 2009 14:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.357 X-Spam-Level: X-Spam-Status: No, score=-9.357 tagged_above=-999 required=5 tests=[AWL=0.631, 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 Pes3R7ARbf7p for ; Wed, 15 Apr 2009 14:21:53 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 08B733A6F3C for ; Wed, 15 Apr 2009 14:21:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 744E663B172; Wed, 15 Apr 2009 21:23:01 +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 B586163B23C for ; Wed, 15 Apr 2009 21:22:57 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA03315; Wed, 15 Apr 2009 17:22:56 -0400 (EDT) From: der Mouse Message-Id: <200904152122.RAA03315@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, 15 Apr 2009 16:28:47 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> Or some other set of cross-linked magic dependencies end up >> requiring something effectively similar. If we do this, it won't be >> the last such piece of negotiation magic, I'm sure of that. > Can you substantiate that feeling? Of course not. How can one substantiate a prediction about the future? > We have one magic interdependency already (keyexchange/hostkey), Hm, that's true. Ugh. I still don't like it, though; this argument feels like "we made this mistake already in the past, so we might as well make it over again in a different way here". (Yes, I realize this phrasing of it is somewhat question-begging, in that it assumes it _is_ a mistake.) More generally, there are two aspects of this AEAD thing that are relevant: there are compatability properties (eg, encryption using an algorithm with a (notional) "aead" property means using a MAC algorithm with a similar property (and only "none" has the "aead" property)), and there are negotiation order dependencies (MAC negotiation depends on encryption negotiation). It's true that each of these is present in kex/hostkey (compatability, in the form of "encrypt" and "sign" properties, and ordering, in the form of "hostkey negotiation depends on the outcome of kex negotiation"). But I don't see how that justifies introducing more of either. > My view is that I don't see much practical or aestetical problems > arising from this particular "magic" dependency, which I think is > similar in spirit to the key exchange/hostkey dependency, and that > the alternatives are worse because they bring more complexity and > hence more bugs. I agree that this is similar in spirit to the kex/hostkey dependency. But, as I said above, that doesn't justify it to me. Are the alternatives worse? I think this is true only if you restrict yourself to a very small subset of the available alternatives - for example, if you insist on doing it within an SSHv2 framework. SSH is not the be-all and end-all of secured communications, and it does not mean there is anything wrong with either SSH or AEAD if the two don't play nice together. The more I think about this, the more I think what's really bugging me about it is yet another form of the cross-product problem. Algorithm negotiation order can be dealt with; each partial order dependency can be registered - separately - with dependency registrations rejected when they would introduce dependency cycles. But the algorithm property problem is much harder. We've got two properties ("sign" and "encrypt") applicable to kex algorithms and host-key algorithms; this AEAD thing introduces another property ("integrated-mac", say) which applies to encryption and MAC algorithms. To do this right (ie, without ambiguities) requires that every new algorithm specify what value it has for every previously-defined property, and every new property specify its value for every previously-defined algorithm. This becomse a huge - and fairly sparse - matrix, and a tremendous load on proposers of new algorithms or properties, since they must understand all propertyes (resp. algorithms) enough to figure out what values to specify. It also is a practical problem in the presence of private algorithms and/or properties, or in the presence of multiple people working on different algorithms and properties simultaneously. > I'm strongly against adding new general option or negotiation > frameworks just to support aead. That's simply not worth the effort. The point is that they _aren't_ "just to support aead". If they were, yes, it would not be worth the bother. They are to support aead _and_ whatever other now-unforeseen issues arise down the line - future-proofing, if you will. Trying to solve the immediate problem right and thereby solve various future problems as well, rather than solving the immediate problem with a kludge that doesn't help and quite likely may actually hinder solving future problems. Akin to the remark in the jargon File that "[r]eal hackers [] generalize uninteresting problems enough to make them interesting and solve them - thus solving the original problem as a special case". /~\ 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 Apr 15 14:26: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 A522E3A6831 for ; Wed, 15 Apr 2009 14:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.190, 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 ld9rbO7dkQRx for ; Wed, 15 Apr 2009 14:26:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C5D2B3A67A7 for ; Wed, 15 Apr 2009 14:26:08 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 91E4D63B1E7; Wed, 15 Apr 2009 21:27:15 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9303863B137 for ; Wed, 15 Apr 2009 21:27:13 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FLRChr003860 for ; Wed, 15 Apr 2009 21:27:13 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 n3FLRCMc049700 for ; Wed, 15 Apr 2009 15:27:12 -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 n3FL2nAd011901; Wed, 15 Apr 2009 16:02:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FL2mqk011900; Wed, 15 Apr 2009 16:02:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:02:48 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Niels =?iso-8859-1?Q?M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415210248.GG1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 03:52:46PM -0400, Jeffrey Hutzelman wrote: > What I'd suggest instead is defining a unique MAC alogrithm for each AEAD > encryption algorithm, which has the same effects as null but is usable > _only_ when the corresponding encryption algorithm is selected. This is a > simple and straightforward modification to the negotiation rules which But not simpler than my proposal: IF an AEAD cipher is selected THEN no MAC alg is selected (since the cipher provides integrity protection all by its lonesome). We should pick the simplest solution that does the job. I don't think you'll find one simpler than the above. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:27: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 400A13A6831 for ; Wed, 15 Apr 2009 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 uiQBPFei5dML for ; Wed, 15 Apr 2009 14:27:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D1AC23A67A7 for ; Wed, 15 Apr 2009 14:27:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E3D063B268; Wed, 15 Apr 2009 21:27:53 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 920A863B123 for ; Wed, 15 Apr 2009 21:27:47 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (host-69-95-83-226.pit.choiceone.net [69.95.83.226]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3FLRehX012987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 17:27:42 -0400 (EDT) Date: Wed, 15 Apr 2009 17:27:40 -0400 From: Jeffrey Hutzelman To: =?UTF-8?Q?Niels_M=C3=B6ller?= cc: der Mouse , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Wednesday, April 15, 2009 11:01:58 PM +0200 Niels M=C3=B6ller=20 wrote: > Jeffrey Hutzelman writes: > >> What I'd suggest instead is defining a unique MAC alogrithm for each >> AEAD encryption algorithm, which has the same effects as null but is >> usable _only_ when the corresponding encryption algorithm is selected. > > I'm not sure I follow precisely what you mean, but I think the > important structural change is that we say that should apply algorithm > selection to the encryption algorithm first, before selecting the mac > algorithm. Yes, we need to say this. The base spec makes the corresponding assertion=20 for keyex and host key algorithms, though with a bit of a twist: - keyex negotiation comes first, but the only algorithms considered are those whose needs are met by at least one host key algorithm the two peers have in common - host key negotiation comes next, and the only host key algorithms considered are those which meet the needs of the selected keyex In the case of encryption and MAC algorithms, I don't think we should have=20 this sort of bidirectional dependency. Rather we should simply say that=20 the encryption algorithm negotiation happens first, which then allows us to = modify the MAC algorithm in ways that depend on knowing which encryption=20 algorithm was selected. > Then the result of the selection of the encryption algorithm may > trigger special behaviour when it comes to the MAC algorithm. The > naive rule "If an AEAD-algorithm is selected for encryption, no other > MAC is used, and it doesn't matter whatsoever what's on the MAC > algorithm lists" is simple and I think it should work, although I'm > open to other variations. I'd prefer not to have that particular rule. I think it would be better to explicitly describe a MAC algorithm which does nothing has no effect, and do one of these: a) Define a rule that allows a MAC algorithm to depend on a particular encryption algorithm (or a particular set of algorithms), such that that MAC algorithm can be considered only if the selected encryption algorithm is one of the ones it depends on. Then define multiple do-nothing MAC algorithms, one per AEAD encryption algorithm, and make them depend on the corresponding AEAD algorithm. b) Allow a MAC algorithm to depend on encrpytion algorithm properties, in the way that keyex algorithms depend on properties of host key algorithms. This means that such an algorithm can be considered only if the selected encryption algorithm has whatever property it depends on. Then specify a single do-nothing MAC algorithm which depends on AEAD encrpytion algorithm. One of the advantages of either of these approaches is that one can choose=20 to use a traditional MAC in addition to an AEAD encryption algorithm, if it = is discovered that the integrity-protection properties of the AEAD=20 algorithm are weaker than previously thought. This would be a fix that=20 could be quickly deployed by making configuration changes using existing=20 MAC algorithms. Approach (a) has the additional advantage that such a=20 workaround can easily be applied only to specific AEAD algorithms. > Implementations not supporting AEAD need of course not know or care > about this rule. A party that advertises only AEAD-algorithms for > encryption can safely list "none" as the only MAC algorithm (IIRC, > it's not allowed to send an empty list, and any value, not just > "none", will work just as well), negotiation with a party not > supporting AEAD will then fail in an orderly manner. ... unless someone decides to implement "none" and not AEAD. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:29: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 061603A6C3B for ; Wed, 15 Apr 2009 14:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFb64yldN2-E for ; Wed, 15 Apr 2009 14:29:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 033953A67A7 for ; Wed, 15 Apr 2009 14:29:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E464C63B23C; Wed, 15 Apr 2009 21:30:36 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 4117163B12C for ; Wed, 15 Apr 2009 21:30:35 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FLUYUw010390 for ; Wed, 15 Apr 2009 21:30:34 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 n3FLUYWu052754 for ; Wed, 15 Apr 2009 15:30:34 -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 n3FLDfXM011913; Wed, 15 Apr 2009 16:13:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FLDeVt011912; Wed, 15 Apr 2009 16:13:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:13:40 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415211340.GI1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <20090415153608.GL1500@Sun.COM> <50DADDE6B33B1B47904E685AAFDC18241A8551AF34@yugi.mocana.local> <200904152010.QAA02715@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 11:05:52PM +0200, Niels Möller wrote: > der Mouse writes: > > >> It doesn't need to be ignored, but the order does matter. AEAD-* > >> algorithms must appear first in the order list. > > > > That's completely unextendable; what happens when another algorithm is > > added that also "must appear first"? > > Agreed. That's not acceptable. > > And besides that, it should be possible to express old-fashioned > preferences, like "I really like triple-DES, but if you don't support > it, I'll go with AEAD as a fallback". Right. My proposal (MAC algs nego irrelvant when AEAD cipher chosen) allows that. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:34:21 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 E28293A6F30 for ; Wed, 15 Apr 2009 14:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.378 X-Spam-Level: X-Spam-Status: No, score=-9.378 tagged_above=-999 required=5 tests=[AWL=0.610, 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 UbsI6hI4zugZ for ; Wed, 15 Apr 2009 14:34:21 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E69C13A6831 for ; Wed, 15 Apr 2009 14:34:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F21BE63B12C; Wed, 15 Apr 2009 21:35:28 +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 8B1FD63B115 for ; Wed, 15 Apr 2009 21:35:27 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA03542; Wed, 15 Apr 2009 17:35:26 -0400 (EDT) From: der Mouse Message-Id: <200904152135.RAA03542@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, 15 Apr 2009 17:32:19 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415182503.GV1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <20090415182503.GV1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > - negotiation of compression only post-authentication (a very useful > and awesome OpenSSH extension) (a) What's so useful about it? (I don't offhand see any reason why it would be better than starting compression at kex time, and I'm wondering what I've missed.) (b) Got a pointer to the spec? I'd like to read up on it and see if I want to implement it. (I would _hope_ that OpenSSH would be, well, open with their extensions - but I was unable to find any spec for keepalive@openssh.com, so maybe not.) /~\ 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 Apr 15 14:35:17 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 3A2163A6F48 for ; Wed, 15 Apr 2009 14:35:17 -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 ntfeE-UV2zpK for ; Wed, 15 Apr 2009 14:35:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 36AC73A6C3B for ; Wed, 15 Apr 2009 14:35:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E95A963B137; Wed, 15 Apr 2009 21:36:23 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 7551E63B1F3 for ; Wed, 15 Apr 2009 21:36:22 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 3E33CC4AFF; Thu, 16 Apr 2009 07:36:20 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id A3750C4AAF; Thu, 16 Apr 2009 07:36:14 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 280A8A4F54; Thu, 16 Apr 2009 07:36:14 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 2738DA4F51; Thu, 16 Apr 2009 07:36:14 +1000 (EST) Date: Thu, 16 Apr 2009 07:36:14 +1000 (EST) From: Damien Miller To: Nicolas Williams cc: =?ISO-8859-15?Q?Niels_M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415182503.GV1500@Sun.COM> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <20090415182503.GV1500@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, Nicolas Williams wrote: > - Retriable initial kex, for example (this is so that GSS-API auth > failure need not lead to the connection being closed). For this I'd > use the reserved unsigned 32-bit int in the KEXINIT as a flags field > -- if both the client and the server have the flag set for re-triable > kex then GSS-API failure should not lead to connection closure. That is a good idea IMO. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:38:38 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 10A0228C286 for ; Wed, 15 Apr 2009 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.189, 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 SNoFjfU90-BJ for ; Wed, 15 Apr 2009 14:38:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1957428C284 for ; Wed, 15 Apr 2009 14:38:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 45D6463B1D0; Wed, 15 Apr 2009 21:39:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id BFA3C63B26E for ; Wed, 15 Apr 2009 21:39:44 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FLdi3T000896 for ; Wed, 15 Apr 2009 21:39:44 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 n3FLdh5F060680 for ; Wed, 15 Apr 2009 15:39:43 -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 n3FLUKnl011933; Wed, 15 Apr 2009 16:30:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FLUKHP011932; Wed, 15 Apr 2009 16:30:20 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:30:20 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415213019.GK1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <200904152122.RAA03315@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904152122.RAA03315@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 04:28:47PM -0400, der Mouse wrote: > > I'm strongly against adding new general option or negotiation > > frameworks just to support aead. That's simply not worth the effort. > > The point is that they _aren't_ "just to support aead". If they were, > yes, it would not be worth the bother. They are to support aead _and_ > whatever other now-unforeseen issues arise down the line - > future-proofing, if you will. Trying to solve the immediate problem The original designers of the SSHv2 kex clearly didn't have the right vision of the future, but, then again, their design mistakes haven't stopped us. I don't believe we can do much better now as, like them then, we cannot necessarily predict the future. Thus I'd rather do the simplest possible solution, which solution I think I've stated something like four or five times today. I'd also like us to clarify how implementors should deal with that reserved uint32 field in KEXINIT today as a way of buying ourselves room for future extensions. For that I propose this: The reserved uint32 field in KEXINIT MUST be set to 0; future specs may specify the meaning of non-zero values and when they may be sent. When a KEXINIT is received that has a non-zero value in the KEXINIT reserved uint32 field, then the receiver MUST ignore both, the reserved uint32 field and any additional bytes in the packet beyond it. Future extensions might treat the reserved uint32 field as a flags field and might specify flags that, when set, indicate that additional data may be found between the reserved field and the end of the KEXINIT packet, and/or that additional new key exchange protocol packets may follow. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:42: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 23A9828C286 for ; Wed, 15 Apr 2009 14:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.398 tagged_above=-999 required=5 tests=[AWL=0.590, 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 d2rIUdeHMw7k for ; Wed, 15 Apr 2009 14:42:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A1AAF28C282 for ; Wed, 15 Apr 2009 14:42:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D0E1663B115; Wed, 15 Apr 2009 21:43:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 65E6363B159 for ; Wed, 15 Apr 2009 21:43:31 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA03648; Wed, 15 Apr 2009 17:43:30 -0400 (EDT) From: der Mouse Message-Id: <200904152143.RAA03648@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, 15 Apr 2009 17:38:13 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415203325.GY1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <20090415203325.GY1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> There has been a security vulnerability [...] >> Thanks. Do you have a pointer to more details? > http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt Got a pointer to anything that actually describes the attack? That page describes only the effect of the attack, not the mechanism, and makes claims that seem dubious to me ("an arbitrary, attacker-selected block of ciphertext", claims that only CBC mode is affected, and the claims here that it's due to encrypting packet lengths - these sound unlikely to me to all be true - but of course that likely just means I'm missing something, which is why I'm interested in more details). /~\ 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 Apr 15 14:50:17 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 AB09D3A6BF8 for ; Wed, 15 Apr 2009 14:50:17 -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 mnViNMIemAAK for ; Wed, 15 Apr 2009 14:50:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5B9823A6831 for ; Wed, 15 Apr 2009 14:50:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7133063B23A; Wed, 15 Apr 2009 21:51:24 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 6B33A63B123 for ; Wed, 15 Apr 2009 21:51:22 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 39DCCC4AFF; Thu, 16 Apr 2009 07:51:20 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id CD297C4AAF; Thu, 16 Apr 2009 07:51:12 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 4FAC3A4F54; Thu, 16 Apr 2009 07:51:12 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 4D3D4A4F51; Thu, 16 Apr 2009 07:51:12 +1000 (EST) Date: Thu, 16 Apr 2009 07:51:12 +1000 (EST) From: Damien Miller To: Nicolas Williams cc: Jeffrey Hutzelman , =?ISO-8859-15?Q?Niels_M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415210248.GG1500@Sun.COM> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, Nicolas Williams wrote: > On Wed, Apr 15, 2009 at 03:52:46PM -0400, Jeffrey Hutzelman wrote: > > What I'd suggest instead is defining a unique MAC alogrithm for each AEAD > > encryption algorithm, which has the same effects as null but is usable > > _only_ when the corresponding encryption algorithm is selected. This is a > > simple and straightforward modification to the negotiation rules which > > But not simpler than my proposal: > > IF an AEAD cipher is selected THEN no MAC alg is selected (since the > cipher provides integrity protection all by its lonesome). > > We should pick the simplest solution that does the job. I don't think > you'll find one simpler than the above. +1 This seems to be the least horrible solution to the problem. It is certainly the easiest to implement, which makes me think that it won't be stuffed up. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:55: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 123BC3A6BBE for ; Wed, 15 Apr 2009 14:55:03 -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=[AWL=0.000, 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 Qne5l4HH-7JR for ; Wed, 15 Apr 2009 14:55:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 028F43A6B3F for ; Wed, 15 Apr 2009 14:55:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 583C463B278; Wed, 15 Apr 2009 21:56:10 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id C1CE063B1C1 for ; Wed, 15 Apr 2009 21:56:08 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id E8F8CC4AFF; Thu, 16 Apr 2009 07:56:06 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id A79B7C4AAF; Thu, 16 Apr 2009 07:56:00 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 2B5EDA4F54; Thu, 16 Apr 2009 07:56:00 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 28FF8A4F51; Thu, 16 Apr 2009 07:56:00 +1000 (EST) Date: Thu, 16 Apr 2009 07:56:00 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904152135.RAA03542@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <20090415182503.GV1500@Sun.COM> <200904152135.RAA03542@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, der Mouse wrote: > > - negotiation of compression only post-authentication (a very useful > > and awesome OpenSSH extension) > > (a) What's so useful about it? (I don't offhand see any reason why it > would be better than starting compression at kex time, and I'm > wondering what I've missed.) Avoiding the attack surface presented by compression libraries before authentication of the user. > (b) Got a pointer to the spec? I'd like to read up on it and see if I > want to implement it. http://tools.ietf.org/html/draft-miller-secsh-compression-delayed-00 -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 14:59:47 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 154BF3A67B0 for ; Wed, 15 Apr 2009 14:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn-S9K-a21lT for ; Wed, 15 Apr 2009 14:59:46 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 00C1A3A67A7 for ; Wed, 15 Apr 2009 14:59:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D4CF863B1F3; Wed, 15 Apr 2009 22:00:50 +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 A64B763B197 for ; Wed, 15 Apr 2009 22:00:48 +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 n3FM0mri016470 for ; Wed, 15 Apr 2009 22:00:48 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 n3FM0lCo062892 for ; Wed, 15 Apr 2009 16:00:47 -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 n3FLLNg3011925; Wed, 15 Apr 2009 16:21:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FLLM6i011924; Wed, 15 Apr 2009 16:21:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:21:22 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: James Blaisdell , Tim Polk , "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415212122.GJ1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> <20090415184118.GW1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 11:15:48PM +0200, Niels Möller wrote: > Nicolas Williams writes: > > > Encrypted packet length will cause more headaches if it means changing > > AEAD APIs. If we really, really want encrypted packet lengths then > > let's use Niels' proposal of using a separate and separately keyed > > non-AEAD cipher to encrypt the packet length and then use the AEAD > > cipher to encrypt the rest of the packet. (Niels' proposal has to > > involve padding the packet length if the non-AEAD cipher used to encrypt > > the packet length is not a counter mode or stream cipher.) > > Actually, I'm suggested that we encrypt the first *block*, not just > the length field, with an independent cipher. The full block is then > authenticated as additional data to AEAD. In the case of AES-GCM, > there's a natural block size, and a reasonable choice for this cipher > is AES-CTR. This way, there's nothing special to the padding. Ah, clever. I'm OK with that as an option. I'd like the option to have unencrypted packet lengths (meaning the first block of encryption starts at byte #4 (zero-based numbering) of the packet. But, actually, I think I was wrong about PKCS#11, it does seem to allow online decryption with AEAD modes. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 15:01:05 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 062F83A67A7 for ; Wed, 15 Apr 2009 15:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.416 X-Spam-Level: X-Spam-Status: No, score=-9.416 tagged_above=-999 required=5 tests=[AWL=0.572, 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 g-13+Iwsyj9f for ; Wed, 15 Apr 2009 15:01:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4520C3A6B3F for ; Wed, 15 Apr 2009 15:00:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BECE863B132; Wed, 15 Apr 2009 22:02:05 +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 F375363B1C1 for ; Wed, 15 Apr 2009 22:02:03 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA03820; Wed, 15 Apr 2009 18:02:02 -0400 (EDT) From: der Mouse Message-Id: <200904152202.SAA03820@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, 15 Apr 2009 17:45:28 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415203845.GA1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <200904152028.QAA02868@Sparkle.Rodents-Montreal.ORG> <20090415203845.GA1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> The leak was enormously compounded by sending the decrypted packet >>> length in a DISCONNECT packet, >> !! It's hardly the fault of the protocol if implementations >> gratuitously leak cribs for attacking the crypto! > Even without the DISCONNECT and syslogging you still leak quite a bit > IFF the packet length decodes to something less than max packet. How? If my response to an invalid packet length is to read the right amount of data for a max-length packet and disconnect, and my response to an invalid MAC is to read as much as necessary to pad to the amount I would have read if the packet length were max-length and then disconnect, I don't see how I'm leaking anything - unless you happen to get the MAC right too, which reduces attack success probability substantially. (Admittedly, this does not describe the behaviour of any implementation, as far as I know.) Or, I suppose, unless you're doing precision timing attacks to determine how much I'm feeding to my MAC computation before going into read-and-discard mode. To defeat that I'd probably have to decrypt the extra garbage (and, ideally, feed it into whatever hashing the MAC algorithm in question does). > Yes, it's unlikely for an active attacker to cause that, since max > packet will usually be on the order of 2^16 but the truly max packet > length is on the order of 2^32, but surely you see the point. Presumnably, the 2^-18, 2^-16, or 2^-14 probability of an attack being successful I've seen cited is due to that: it works only when the decrypted length has enough zero high-order bits that the attacker can tell it from random garbage. But I've been staring at CBC and haven't been able to see how knowing that is useful to the attacker - except as a partial crib for attacking the bulk crypto, which is not what the descriptions sound like. /~\ 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 Apr 15 15:06: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 D387E3A683A for ; Wed, 15 Apr 2009 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.188, 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 Mb9FPfQazavr for ; Wed, 15 Apr 2009 15:06:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 833623A6950 for ; Wed, 15 Apr 2009 15:06:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 14B0563B123; Wed, 15 Apr 2009 22:07:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id ED34663B10D for ; Wed, 15 Apr 2009 22:07:48 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FM7mZE004021 for ; Wed, 15 Apr 2009 22:07:48 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 n3FM7mxg002703 for ; Wed, 15 Apr 2009 16:07:48 -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 n3FLwOc1011949; Wed, 15 Apr 2009 16:58:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FLwM0V011948; Wed, 15 Apr 2009 16:58:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 16:58:22 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415215822.GM1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <20090415182503.GV1500@Sun.COM> <200904152135.RAA03542@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904152135.RAA03542@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 05:32:19PM -0400, der Mouse wrote: > > - negotiation of compression only post-authentication (a very useful > > and awesome OpenSSH extension) > > (a) What's so useful about it? (I don't offhand see any reason why it > would be better than starting compression at kex time, and I'm > wondering what I've missed.) Our implementation (SunSSH) has a different approach to PrivSep than OpenSSH. We recognize that doing privsep pre-authentication gets no real privilege separation[*] for any components other than compression. So SunSSH's sshd does privsep only post-authentication, which keeps its montior protocol very very simple. Therefore we'd like to defer compression to post-authentication [*] We noticed that the monitor protocol for supporting pre-auth privsep was not materially simpler than the pre-auth parts of SSHv2 (i.e., the monitor protocol was quite complex). Buffer overflow attacks on the crypto are not likely (until the recent SHA-3 submissions I was unaware of any such buffer overflows), but buffer overflow vulnerabilities against zlib are nothing new. Therefore privilege separation for zlib would be nice, and the simplest way to do it is to defer it to post-authentication. Besides, there's very little that can be compressed or is worth compressing between key exchange and authentication. See: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ssh/README.altprivsep > (b) Got a pointer to the spec? I'd like to read up on it and see if I > want to implement it. (I would _hope_ that OpenSSH would be, well, > open with their extensions - but I was unable to find any spec for > keepalive@openssh.com, so maybe not.) http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL?rev=1.12;content-type=text%2Fplain Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 15:13: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 254393A6899 for ; Wed, 15 Apr 2009 15:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=0.188, 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 uwL5VHDAbcPn for ; Wed, 15 Apr 2009 15:13:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 085F33A6954 for ; Wed, 15 Apr 2009 15:13:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 51CD463B1A6; Wed, 15 Apr 2009 22:14:41 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id EF6C963B191 for ; Wed, 15 Apr 2009 22:14:39 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FMEdan019893 for ; Wed, 15 Apr 2009 22:14:39 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 n3FMEcp2017586 for ; Wed, 15 Apr 2009 16:14:39 -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 n3FM5Ft6011957; Wed, 15 Apr 2009 17:05:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FM5FHG011956; Wed, 15 Apr 2009 17:05:15 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 17:05:15 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415220515.GN1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <20090415203325.GY1500@Sun.COM> <200904152143.RAA03648@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904152143.RAA03648@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, Apr 15, 2009 at 05:38:13PM -0400, der Mouse wrote: > >>> There has been a security vulnerability [...] > >> Thanks. Do you have a pointer to more details? > > http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt > > Got a pointer to anything that actually describes the attack? That > page describes only the effect of the attack, not the mechanism, and > makes claims that seem dubious to me ("an arbitrary, attacker-selected > block of ciphertext", claims that only CBC mode is affected, and the > claims here that it's due to encrypting packet lengths - these sound > unlikely to me to all be true - but of course that likely just means > I'm missing something, which is why I'm interested in more details). I don't recall where the attack is described. Briefly: an active attacker replaces what he/she knows to be an encrypted packet length with bytes that he/she knows correspond to an encrypted password, then after that sends the remainder of the packet (possibly garbage) one byte/block at a time. The information leak about the incorrect packet length may reveal some number of bits of the password. That number depends on how much information is leaked. If the packet length decrypted to something > max packet length and the length was not syslogged to a remote host and not sent back to the client (which the user might then quote w/o privacy protection to a helpdesk), then the attacker learns very little. If the packet length decrypted to something < max packet length and there's no syslog/disconnect leak then the attacker recovers 16 - block size bits of the password. If the attacker recovers the decrypted packet length from syslog or the disconnect sent to the user, then the attacker recovers four bytes of the password. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 15:35:20 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 155013A69A8 for ; Wed, 15 Apr 2009 15:35:20 -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=[AWL=0.000, 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 wtjLVE2ct-LP for ; Wed, 15 Apr 2009 15:35:19 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 02CB23A67AC for ; Wed, 15 Apr 2009 15:35:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 11FDC63B1C1; Wed, 15 Apr 2009 22:36:19 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 093A563B1B0 for ; Wed, 15 Apr 2009 22:36:11 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 3B1D3C4AFF; Thu, 16 Apr 2009 08:36:08 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 9138FC4AAF; Thu, 16 Apr 2009 08:36:00 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 0BE1FA4F54; Thu, 16 Apr 2009 08:36:00 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 097E6A4F51; Thu, 16 Apr 2009 08:36:00 +1000 (EST) Date: Thu, 16 Apr 2009 08:36:00 +1000 (EST) From: Damien Miller To: Nicolas Williams cc: Jeffrey Hutzelman , =?ISO-8859-15?Q?Niels_M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415220602.GO1500@Sun.COM> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090415220602.GO1500@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Wed, 15 Apr 2009, Nicolas Williams wrote: > > This seems to be the least horrible solution to the problem. It is > > certainly the easiest to implement, which makes me think that it won't > > be stuffed up. > > Jeff Hutzelman objects that this violates the abstraction that the > transport layer defines the binary packet encoding. I don't give a > damn. I don't see how this objection works: KEX (inc. cipher/mac negotiation) determines the parameters for the transport protocol. How does a KEX change violate the transport abstraction? -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 15:36: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 28A9C3A67AC for ; Wed, 15 Apr 2009 15:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.187, 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 Kkl9WOGPIaPc for ; Wed, 15 Apr 2009 15:36:50 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 19C813A6802 for ; Wed, 15 Apr 2009 15:36:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 95DC763B197; Wed, 15 Apr 2009 22:38:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id DAE0763B136 for ; Wed, 15 Apr 2009 22:37:58 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3FMbwtV008189 for ; Wed, 15 Apr 2009 22:37:58 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 n3FMbw5D032032 for ; Wed, 15 Apr 2009 16:37:58 -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 n3FM630o011963; Wed, 15 Apr 2009 17:06:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FM623P011962; Wed, 15 Apr 2009 17:06:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 15 Apr 2009 17:06:02 -0500 From: Nicolas Williams To: Damien Miller Cc: Jeffrey Hutzelman , Niels =?iso-8859-1?Q?M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090415220602.GO1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 07:51:12AM +1000, Damien Miller wrote: > On Wed, 15 Apr 2009, Nicolas Williams wrote: > > > On Wed, Apr 15, 2009 at 03:52:46PM -0400, Jeffrey Hutzelman wrote: > > > What I'd suggest instead is defining a unique MAC alogrithm for each AEAD > > > encryption algorithm, which has the same effects as null but is usable > > > _only_ when the corresponding encryption algorithm is selected. This is a > > > simple and straightforward modification to the negotiation rules which > > > > But not simpler than my proposal: > > > > IF an AEAD cipher is selected THEN no MAC alg is selected (since the > > cipher provides integrity protection all by its lonesome). > > > > We should pick the simplest solution that does the job. I don't think > > you'll find one simpler than the above. > > +1 > > This seems to be the least horrible solution to the problem. It is > certainly the easiest to implement, which makes me think that it won't > be stuffed up. Jeff Hutzelman objects that this violates the abstraction that the transport layer defines the binary packet encoding. I don't give a damn. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 15:46:05 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 893813A6A70 for ; Wed, 15 Apr 2009 15:46:05 -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 UgIJOjZEewzS for ; Wed, 15 Apr 2009 15:46:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 968ED3A6A96 for ; Wed, 15 Apr 2009 15:45:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 61EA063B2B2; Wed, 15 Apr 2009 22:46:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 2D39663B29D for ; Wed, 15 Apr 2009 22:46:40 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.63) (envelope-from ) id 1LuDsH-000542-U2; Wed, 15 Apr 2009 23:46:33 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org Cc: der Mouse In-Reply-To: <200904152202.SAA03820@Sparkle.Rodents-Montreal.ORG> Subject: Re: applying AES-GCM to secure shell: proposed "tweak" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 15 Apr 2009 23:46:33 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse wrote: > Presumnably, the 2^-18, 2^-16, or 2^-14 probability of an attack being > successful I've seen cited is due to that: it works only when the > decrypted length has enough zero high-order bits that the attacker can > tell it from random garbage. But I've been staring at CBC and haven't > been able to see how knowing that is useful to the attacker - except as > a partial crib for attacking the bulk crypto, which is not what the > descriptions sound like. You don't use it to attack the bulk crypto: you use it to get a partial decryption of a particular cipher block. So you start by traffic-analysing the session to identify a block you'd like to know the plaintext of (e.g. the one that occurs at the right point within SSH_MSG_PASSWORD); then you inject that same cipher block in place of the length-containing block of a later packet, in the hope of finding out something about its contents. If you find out that the block decrypts to some valid packet length in the latter context, then you can XOR in the difference between the previous cipher blocks in both contexts to determine part of what the same block decrypted to the first time round. (Since the attack can only be used against a block from the same session and you expect to splatter 2^18 connections before getting a result, you'd only want to use it against some data which reliably occurs in lots of sessions and which you desperately want to know. The password packet is probably the only practical target, in almost all circumstances.) -- Simon Tatham "Imagine what the world would be like if there were no hypothetical situations..." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 16:04:22 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 9CB7B3A698C for ; Wed, 15 Apr 2009 16:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.433 X-Spam-Level: X-Spam-Status: No, score=-9.433 tagged_above=-999 required=5 tests=[AWL=0.555, 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 K4H0PbBQt-1H for ; Wed, 15 Apr 2009 16:04:21 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id EDB6D3A67AC for ; Wed, 15 Apr 2009 16:04:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A9C463B38A; Wed, 15 Apr 2009 23:05:14 +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 0B4FD63B306 for ; Wed, 15 Apr 2009 23:05:06 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id TAA04603; Wed, 15 Apr 2009 19:05:05 -0400 (EDT) From: der Mouse Message-Id: <200904152305.TAA04603@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, 15 Apr 2009 18:41:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090415220515.GN1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <20090415203325.GY1500@Sun.COM> <200904152143.RAA03648@Sparkle.Rodents-Montreal.ORG> <20090415220515.GN1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > If the packet length decrypted to something < max packet length and > there's no syslog/disconnect leak then the attacker recovers 16 - > block size bits of the password. Hmm. Thank you. Even that much, though, depends on the server disconnecting as soon as it discovers the wrong MAC, and thereby leaking the decrypted length to within the cipher's block size, doesn't it? Also, ISTM the attacker recovers more than 16 bits; if the attacker knows the packet size as revealed by disconnect timing (which this seems to be entirely predicated upon), that reveals the exact packet length field (since the length includes all padding, and thus knowledge of the number of cryptosystem blocks in the packet gives the exact packet_length value). Combined with the attacker's presumed knowledge of the previous ciphertext block in CBC mode, this reveals a full 32 bits of data from the block of interest. Is this analysis wrong? I also note it works only on data at the beginnings of blocks - this is useless to an attacker who wants something beyond the first four bytes of a cryptosystem block. Fortunately, it's fairly easy to frustrate. The first technique that comes to mind is one I sketched upthread, which the receiver can implement: react to bad packet lengths or invalid MACs by reading data out to the maximum valid packet length before disconnecting. The second is something the sender can implement: rather than pausing transmission at packet boundaries, always pad with an IGNORE packet - and write only part of (the encrypted version of) it. This makes it harder for the attacker to find the length field in the data stream. (This one provides only a few more bits of protection, since the attacker can just guess at how much of the IGNORE packet the sender is holding queued, but every additional bit of difficulty is another factor of two less practicality. And when the line is idle is when you least mind inserting largeish amounts of pad data.) And, of course, not using CBC ciphers breaks it totally. /~\ 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 Apr 15 16:12: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 0E3643A67AD for ; Wed, 15 Apr 2009 16:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.45 X-Spam-Level: X-Spam-Status: No, score=-9.45 tagged_above=-999 required=5 tests=[AWL=0.538, 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 iE8xHHIYUUBa for ; Wed, 15 Apr 2009 16:12:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id ECC833A67B5 for ; Wed, 15 Apr 2009 16:12:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DAAD063B324; Wed, 15 Apr 2009 23:14:01 +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 602D863B159 for ; Wed, 15 Apr 2009 23:13:59 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id TAA04735; Wed, 15 Apr 2009 19:13:58 -0400 (EDT) From: der Mouse Message-Id: <200904152313.TAA04735@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, 15 Apr 2009 19:08:46 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: SSH_MSG_KEXINIT extensions field [was Re: applying AES-GCM to secure shell: proposed "tweak"] In-Reply-To: <20090415213019.GK1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <200904151536.LAA00772@Sparkle.Rodents-Montreal.ORG> <200904152122.RAA03315@Sparkle.Rodents-Montreal.ORG> <20090415213019.GK1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > I'd also like us to clarify how implementors should deal with that > reserved uint32 field in KEXINIT today as a way of buying ourselves > room for future extensions. That, I totally agree with. The current situation doesn't really give us any way to use that field for anything. > For that I propose this: > The reserved uint32 field in KEXINIT MUST be set to 0; future > specs may specify the meaning of non-zero values and when they > may be sent. > When a KEXINIT is received that has a non-zero value in the > KEXINIT reserved uint32 field, then the receiver MUST ignore > both, the reserved uint32 field and any additional bytes in the > packet beyond it. > Future extensions might [...] (I'd also make explicit the implied change to SSH_MSG_KEXINIT, adding optional additional data of unspecified size after the uint32 in question, with the restriction that if the value is zero there must be no additional data.) This sounds good to me. I support this proposal, in case anyone cares what I think. /~\ 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 Apr 15 16:50:24 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 9FD993A6965 for ; Wed, 15 Apr 2009 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, 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 UkfsWe-VC-cz for ; Wed, 15 Apr 2009 16:50:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id D39D23A67B5 for ; Wed, 15 Apr 2009 16:50:23 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0CFDD63B24C; Wed, 15 Apr 2009 23:51:28 +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 3E6BC63B237 for ; Wed, 15 Apr 2009 23:51:25 +0000 (UTC) Received: from Atlantic ([69.57.253.76]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for ietf-ssh@NetBSD.org; Wed, 15 Apr 2009 19:52:04 -0400 Message-ID: <7258CFCCAB9E4670BBAB8B04CCC0FAB8@Atlantic> From: "denis bider \(Bitvise\)" To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <20090415155941.GM1500@Sun.COM> <200904152028.QAA02868@Sparkle.Rodents-Montreal.ORG> <20090415203845.GA1500@Sun.COM> In-Reply-To: <20090415203845.GA1500@Sun.COM> Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Date: Wed, 15 Apr 2009 19:51:43 -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.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > Even without the DISCONNECT and syslogging you still leak quite a bit > IFF the packet length decodes to something less than max packet. Yes, > it's unlikely for an active attacker to cause that, since max packet > will usually be on the order of 2^16 but the truly max packet length is > on the order of 2^32, but surely you see the point. It is not necessary to leak anything. If decoded packet length is invalid or exceeds MaxPacketLength (e.g. 2^16), then: 1. Select a random valid packet length between MinPacketLength and MaxPacketLength. 2. Read the randomly selected amount of data. 3. Choke as if MAC is incorrect. This prevents the attacker from knowing whether the info they're getting is useful or not, and the likelihood is 1 against 2^N that it's not. denis From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 21:06:59 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 160303A69DC for ; Wed, 15 Apr 2009 21:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 IZRUdXpPzReM for ; Wed, 15 Apr 2009 21:06:58 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2792B3A6976 for ; Wed, 15 Apr 2009 21:06:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9161E63B237; Thu, 16 Apr 2009 04:08:03 +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 9382E63B26E for ; Thu, 16 Apr 2009 04:07:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 465291B73F; Thu, 16 Apr 2009 16:07: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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YhgTRKhEqMD; Thu, 16 Apr 2009 16:07: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 8148E1B3B7; Thu, 16 Apr 2009 16:07: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 691001DE4001; Thu, 16 Apr 2009 16:07:47 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LuIt9-0006tR-7Z; Thu, 16 Apr 2009 16:07:47 +1200 From: Peter Gutmann To: djm@mindrot.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Thu, 16 Apr 2009 16:07:47 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Damien Miller writes: >Avoiding the attack surface presented by compression libraries before >authentication of the user. This is pretty much the main reason why I haven't implemented it so far. zlib has had quite a number of security holes, and (from looking at the code in the past) there are no doubt lots still in there - it's a huge body of incredibly complex and not entirely comprehensible code (do you want to analyse inflate.c/inffast.c and check that there's no potential for overflow/underflow/overwrite/whatever in there?). Having all that exposed to arbitrary remote attackers is too big a risk to take. (I've never really understood why the compression starts where it does anyway, what's being exchanged at that point is mostly random incompressible binary gunk so it has little to no effect on data size anyway). >http://tools.ietf.org/html/draft-miller-secsh-compression-delayed-00 Hmm, why not just apply it only to the data packets? The random non-data- related messages exchanged (again, mostly high-entropy binary blobs) aren't going to compress much (if at all), and will only have the effect of messing up the compression by polluting the source statistics. With data-payload-only compression it'd be much cleaner and easier to handle, just run the compressor over the data-packet payload and leave everything else as is. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 21:14:39 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 B1D2A3A6CC0 for ; Wed, 15 Apr 2009 21:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.016 X-Spam-Level: X-Spam-Status: No, score=-6.016 tagged_above=-999 required=5 tests=[AWL=0.583, 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 a+yF39A2IW32 for ; Wed, 15 Apr 2009 21:14:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 6A2E13A6811 for ; Wed, 15 Apr 2009 21:14:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BE7D363B1D4; Thu, 16 Apr 2009 04:15:35 +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 56DDF63B18C for ; Thu, 16 Apr 2009 04:15:34 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C4CA01B752; Thu, 16 Apr 2009 16:15:33 +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 St1bu2-HJFJw; Thu, 16 Apr 2009 16:15:33 +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 A44011B749; Thu, 16 Apr 2009 16:15: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 9B8781DE4001; Thu, 16 Apr 2009 16:15:33 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LuJ0f-0007OS-Ed; Thu, 16 Apr 2009 16:15:33 +1200 From: Peter Gutmann To: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: ietf-ssh@NetBSD.org In-Reply-To: <20090415220515.GN1500@Sun.COM> Message-Id: Date: Thu, 16 Apr 2009 16:15:33 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: >I don't recall where the attack is described. It's in a conference paper that hasn't been published yet, to appear at the IEEE Oakland conference in... May, I think. [Pause] Yup, see http://oakland09.cs.virginia.edu/papers.html. >Briefly: an active attacker replaces what he/she knows to be an encrypted >packet length with bytes that he/she knows correspond to an encrypted >password, then after that sends the remainder of the packet (possibly >garbage) one byte/block at a time. It's interesting to note here that there have been a number of attacks (of which this is the latest) on encrypted lengths, but none on plaintext lengths as used by TLS. In other words the "more secure" option used by SSH is actually less secure than the "less secure" option of not encrypting, the cause being the unnecessary complexity of processing that this introduces (see my earlier posts in this thread, and I still owe people some replies for one or two of those, sorry). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 15 21:21:07 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 8D9723A6CEA for ; Wed, 15 Apr 2009 21:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, 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 SKJRUFdshs8S for ; Wed, 15 Apr 2009 21:21:06 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 27A7A3A6BE1 for ; Wed, 15 Apr 2009 21:20:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 14A5D63B1E9; Thu, 16 Apr 2009 04:21:46 +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 406D763B27F for ; Thu, 16 Apr 2009 04:21:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3DEB46684BF; Thu, 16 Apr 2009 16:21:43 +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 DEiIYKKSyD4i; Thu, 16 Apr 2009 16:21:43 +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 1F70F66849E; Thu, 16 Apr 2009 16:21:43 +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 189B21DE4001; Thu, 16 Apr 2009 16:21:43 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LuJ6c-0007sn-Vd; Thu, 16 Apr 2009 16:21:43 +1200 From: Peter Gutmann To: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: ietf-ssh@NetBSD.org In-Reply-To: <20090415213019.GK1500@Sun.COM> Message-Id: Date: Thu, 16 Apr 2009 16:21:42 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Nicolas Williams writes: > When a KEXINIT is received that has a non-zero value in the KEXINIT > reserved uint32 field, then the receiver MUST ignore both, the > reserved uint32 field and any additional bytes in the packet beyond > it. I'm not sure that this length-extension will work. The spec has always said that the packet ends at the reserved field, but this would change it to say that it can now continue more or less arbitrarily beyond this point. What will existing implementations do if they see garbage beyond this point? I'd also rephrase the above a bit to say: When a KEXINIT is received that has a non-zero value in the KEXINIT reserved uint32 field and the receiver can't process a non-zero value then it MUST ignore it. The original text seems to say "this value must always be ignored", the new text says "if you don't know what the significance of the flags are, ignore them". Well OK, it says it rather badly, I'm open to suggestions for better phrasings. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 00:55:17 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 7524B3A6C8C for ; Thu, 16 Apr 2009 00:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.465 X-Spam-Level: X-Spam-Status: No, score=-9.465 tagged_above=-999 required=5 tests=[AWL=0.523, 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 coYEczx+CN8Q for ; Thu, 16 Apr 2009 00:55:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 7E25D3A6961 for ; Thu, 16 Apr 2009 00:55:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5436663B1CE; Thu, 16 Apr 2009 07:56:22 +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 4D47163B1CD for ; Thu, 16 Apr 2009 07:56:16 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id DAA07579; Thu, 16 Apr 2009 03:56:16 -0400 (EDT) From: der Mouse Message-Id: <200904160756.DAA07579@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: Thu, 16 Apr 2009 03:39:15 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> Avoiding the attack surface presented by compression libraries >> before authentication of the user. That strikes me as a desirable end. But the I-D I saw named upthread doesn't look like a good way to do it. When the server starts compressing is well-defined, but the point in the client->server data stream at which the client starts compressing is, from the point of view of the server, ill-defined; the only way I see to make it well-defined as the algorithm is defined is for the client to never send anything, even IGNORE or other such messages, between the time it sends a packet which could provoke a USERAUTH_SUCCESS response and the time it receives some kind of response to it. However, the spec does not specify anything of the sort - leaving, I believe, this ill-defined. > Hmm, why not just apply it only to the data packets? That makes sense to me (and seems well-defined, at least once you specify precisely what "data packets" are, presumably SSH_MSG_CHANNEL_DATA, maybe SSH_MSG_CHANNEL_EXTENDED_DATA, possibly a few others such as SSH_MSG_CHANNEL_WINDOW_ADJUST). I may try implementing it. > The random non-data-related messages exchanged (again, mostly > high-entropy binary blobs) aren't going to compress much (if at all), I disagree. There are a lot of non-data messages that are full of uint32 fields that typically have at least 3/4 of their bits zero. Some even use a 32-bit field to carry one bit of information. Compressing these is valuable from the point of view of providing higher-entropy data as the cleartext to the encryption algorithm and therefore making it harder to attack. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 01:06:17 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 0128128C0FE for ; Thu, 16 Apr 2009 01:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lSW5llQyCQ70 for ; Thu, 16 Apr 2009 01:06:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 319523A68B3 for ; Thu, 16 Apr 2009 01:06:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0883363B135; Thu, 16 Apr 2009 08:07:25 +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 AE73063B193 for ; Thu, 16 Apr 2009 08:07:21 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1425A40030; Thu, 16 Apr 2009 10:07:05 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 07D8840031; Thu, 16 Apr 2009 10:07:05 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id E625940030; Thu, 16 Apr 2009 10:07:04 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3G87JGE001790; Thu, 16 Apr 2009 10:07:19 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3G87IAk001787; Thu, 16 Apr 2009 10:07:18 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 16 Apr 2009 10:07:18 +0200 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 15 Apr 2009 17:27:40 -0400") 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 Jeffrey Hutzelman writes: > I'd prefer not to have that particular rule. I think it would be better > to explicitly describe a MAC algorithm which does nothing has no effect, > and do one of these: [...] > b) Allow a MAC algorithm to depend on encrpytion algorithm properties, > in the way that keyex algorithms depend on properties of host key > algorithms. This means that such an algorithm can be considered > only if the selected encryption algorithm has whatever property it > depends on. Then specify a single do-nothing MAC algorithm which > depends on AEAD encrpytion algorithm. This makes sense to me. I'd prefer this option, then. The name could be "none-if-aead". >> Implementations not supporting AEAD need of course not know or care >> about this rule. A party that advertises only AEAD-algorithms for >> encryption can safely list "none" as the only MAC algorithm (IIRC, >> it's not allowed to send an empty list, and any value, not just >> "none", will work just as well), negotiation with a party not >> supporting AEAD will then fail in an orderly manner. > > ... unless someone decides to implement "none" and not AEAD. In this scenario, the mac selection may end up with "none", but the intersection of the encryption algorithm lists will be empty, and hence negotiation fails. Right? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 01:21:06 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 4D98A3A6A89 for ; Thu, 16 Apr 2009 01:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.027, 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 0WPwXpojV9+6 for ; Thu, 16 Apr 2009 01:21:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 12A0B28C137 for ; Thu, 16 Apr 2009 01:21:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C5D4D63B11D; Thu, 16 Apr 2009 08:22:09 +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 D267463B131 for ; Thu, 16 Apr 2009 08:22:07 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 60FCE4000C; Thu, 16 Apr 2009 10:21:50 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 4BE8040017; Thu, 16 Apr 2009 10:21:50 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 3206E4000C; Thu, 16 Apr 2009 10:21:50 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3G8M4Et002294; Thu, 16 Apr 2009 10:22:04 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3G8M344002293; Thu, 16 Apr 2009 10:22:03 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 16 Apr 2009 10:22:03 +0200 In-Reply-To: <20090415210248.GG1500@Sun.COM> (Nicolas Williams's message of "Wed, 15 Apr 2009 16:02:48 -0500") 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 Nicolas Williams writes: > But not simpler than my proposal: > > IF an AEAD cipher is selected THEN no MAC alg is selected (since the > cipher provides integrity protection all by its lonesome). To be precise, does this mean that the mac-list is ignored, or that the *result* of that selection is ignored? Consider the following advertised lists: Client: enc="aead", mac="hmac-sha1" Server: enc="aead", mac="hmac-md5" Should the algorithm selection succeed, settling on aead and no additional mac, or fail because there's no common mac? Or to make it more complicated, what should be the result of: Client: enc="3des-cbc,aead", mac="hmac-sha1" Server: enc="3des-cbc,aead", mac="hmac-md5" We can either fail, since is 3des-cbc selected for encryption, but there's no common mac, or succeed if we notice that there's no common mac, and then filter out all non-AEAD options for encryption. This kind-of contradicts Jeffrey Hutzelman's wish : In the case of encryption and MAC algorithms, I don't think we should : have this sort of bidirectional dependency. and without thinking deeply, I suspect the situation is quite similar to the keyexchange/hostkey dependency, and that we should make about the same level of effort to find a working combination in both cases. I don't implement any keyexchange method that requires encryption, maybe someone that does and understands this better can enlighten me? Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 01:42:40 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 8A1C53A6BC3 for ; Thu, 16 Apr 2009 01:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.025, 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 fJMcYEgjKIGw for ; Thu, 16 Apr 2009 01:42:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B2EE43A6B14 for ; Thu, 16 Apr 2009 01:42:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1935763B131; Thu, 16 Apr 2009 08:43:46 +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 03D0C63B1C9 for ; Thu, 16 Apr 2009 08:43:42 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 3FC7640009; Thu, 16 Apr 2009 10:43:23 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 337B24000C; Thu, 16 Apr 2009 10:43:23 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 142CF40009; Thu, 16 Apr 2009 10:43:23 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3G8hbxh003089; Thu, 16 Apr 2009 10:43:37 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3G8hW1N003088; Thu, 16 Apr 2009 10:43:32 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Nicolas Williams Cc: James Blaisdell , Tim Polk , "ietf-ssh@netbsd.org" , Tero Kivinen , Bill Sommerfeld , Chris Lonvick , "ylo@ssh.com" , "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <50DADDE6B33B1B47904E685AAFDC18241A8551AF21@yugi.mocana.local> <20090415184118.GW1500@Sun.COM> <20090415212122.GJ1500@Sun.COM> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 16 Apr 2009 10:43:31 +0200 In-Reply-To: <20090415212122.GJ1500@Sun.COM> (Nicolas Williams's message of "Wed, 15 Apr 2009 16:21:22 -0500") 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 Nicolas Williams writes: > But, actually, I think I was wrong about PKCS#11, it does seem to allow > online decryption with AEAD modes. Good to hear, thanks for checking. If this is indeed a feature that is typical of aead implementations (as seems to be the case), is there any remaining reason not to use it and handle the encrypted length field in the same way as for other encryption algorithms? Do you reduce possibilities for attacks if you use separate ciphers for the first blocks and the rest of the data? IIRC, the attacks that has been mentioned all rely on cbc, so they are not effective against aes-gcm. Ideally, I guess it would be best to send 1. first block (encrypted and including length field), 2. mac of first block 3. rest of message (encrypted) 4. mac of complete message but this is probably not the right time to make changes like that. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 02:34:23 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 0B1E53A680A for ; Thu, 16 Apr 2009 02:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VPt9S2r52Dlz for ; Thu, 16 Apr 2009 02:34:21 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id BF5F43A6B14 for ; Thu, 16 Apr 2009 02:34:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 947C863B1DB; Thu, 16 Apr 2009 09:35:26 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp7.xenetic.net (smtp7.xenetic.net [80.88.176.189]) (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 BFF9763B138 for ; Thu, 16 Apr 2009 09:35:24 +0000 (UTC) Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp7.xenetic.net (8.14.3/8.14.3) with ESMTP id n3G9ZGui032223; Thu, 16 Apr 2009 12:35:16 +0300 Received: from [10.1.254.253] ([10.1.254.253]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 12:35:15 +0300 Message-ID: <49E6FBD3.4040601@ssh.com> Date: Thu, 16 Apr 2009 12:35:15 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Apr 2009 09:35:15.0850 (UTC) FILETIME=[A613BEA0:01C9BE76] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4,1.2.40,4.0.166 definitions=2009-04-16_04:2009-04-15,2009-04-16,2009-04-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904160030 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Niels Möller wrote: >> b) Allow a MAC algorithm to depend on encrpytion algorithm properties, >> in the way that keyex algorithms depend on properties of host key >> algorithms. This means that such an algorithm can be considered >> only if the selected encryption algorithm has whatever property it >> depends on. Then specify a single do-nothing MAC algorithm which >> depends on AEAD encrpytion algorithm. > > This makes sense to me. I'd prefer this option, then. The name could > be "none-if-aead". I must say I really hate this one. Instead of one simply defined "magic" cipher algorithm name that would have, if selected, a side effect of abolishing MAC, we would have a "magic" MAC name with much more complicated interdependency to cipher list. To make it even more clear, the cipher name for aead could me something like "aes128-aead-nomac". Then if someone likes to implement aead with additional mac (I don't know why anyone would do that) then "aes128-aead@foo.bar" kind of name could be used. -- Timo J. Rinne Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:26: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 66C273A6D1A for ; Thu, 16 Apr 2009 03:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=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 yJxgLNL3GyyX for ; Thu, 16 Apr 2009 03:26:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B015F3A6F3A for ; Thu, 16 Apr 2009 03:26:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9F46B63B20B; Thu, 16 Apr 2009 10:27:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id D435163B22B for ; Thu, 16 Apr 2009 10:27:10 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 04A86C4BB1; Thu, 16 Apr 2009 20:27:07 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 2A5C8C4AFF; Thu, 16 Apr 2009 20:27:02 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id AB841A4F54; Thu, 16 Apr 2009 20:27:01 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id A9116A4F51; Thu, 16 Apr 2009 20:27:01 +1000 (EST) Date: Thu, 16 Apr 2009 20:27:01 +1000 (EST) From: Damien Miller To: =?ISO-8859-15?Q?Niels_M=F6ller?= cc: Nicolas Williams , Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 16 Apr 2009, Niels M?ller wrote: > Nicolas Williams writes: > > > But not simpler than my proposal: > > > > IF an AEAD cipher is selected THEN no MAC alg is selected (since the > > cipher provides integrity protection all by its lonesome). > > To be precise, does this mean that the mac-list is ignored, or that > the *result* of that selection is ignored? Consider the following > advertised lists: > > Client: enc="aead", mac="hmac-sha1" > Server: enc="aead", mac="hmac-md5" > > Should the algorithm selection succeed, settling on aead and no > additional mac, or fail because there's no common mac? > > Or to make it more complicated, what should be the result of: > > Client: enc="3des-cbc,aead", mac="hmac-sha1" > Server: enc="3des-cbc,aead", mac="hmac-md5" > > We can either fail, since is 3des-cbc selected for encryption, but > there's no common mac, or succeed if we notice that there's no common > mac, and then filter out all non-AEAD options for encryption. Nice catch. Intuitively, the easiest way to avoid this is to specify that symmetric cipher agreement must occur before MAC agreement. Most implementations probably do this already. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:27: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 AEAF03A6803 for ; Thu, 16 Apr 2009 03:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_14=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 GSvqBrcPZfmU for ; Thu, 16 Apr 2009 03:27:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B310C3A67D9 for ; Thu, 16 Apr 2009 03:27:30 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 936E963B199; Thu, 16 Apr 2009 10:28:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 2E85263B204 for ; Thu, 16 Apr 2009 10:28:39 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 4B23FC4C67; Thu, 16 Apr 2009 20:28:37 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 51960C4AFF; Thu, 16 Apr 2009 20:28:31 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id DF297A4F54; Thu, 16 Apr 2009 20:28:30 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id DE47AA4F51; Thu, 16 Apr 2009 20:28:30 +1000 (EST) Date: Thu, 16 Apr 2009 20:28:30 +1000 (EST) From: Damien Miller To: "Timo J. Rinne" cc: =?ISO-8859-15?Q?Niels_M=F6ller?= , Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <49E6FBD3.4040601@ssh.com> Message-ID: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <49E6FBD3.4040601@ssh.com> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 16 Apr 2009, Timo J. Rinne wrote: > Niels M?ller wrote: > > > b) Allow a MAC algorithm to depend on encrpytion algorithm properties, > > > in the way that keyex algorithms depend on properties of host key > > > algorithms. This means that such an algorithm can be considered > > > only if the selected encryption algorithm has whatever property it > > > depends on. Then specify a single do-nothing MAC algorithm which > > > depends on AEAD encrpytion algorithm. > > > > This makes sense to me. I'd prefer this option, then. The name could > > be "none-if-aead". > > I must say I really hate this one. Instead of one simply defined > "magic" cipher algorithm name that would have, if selected, a side > effect of abolishing MAC, we would have a "magic" MAC name with much > more complicated interdependency to cipher list. Yes, I don't think this one either. It seems like more extensive special-casing or more complex (read: brittle) selection rules would be required to make this work reliably. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:29:19 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 587963A6AC6 for ; Thu, 16 Apr 2009 03:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 OzAyLxzNQhDI for ; Thu, 16 Apr 2009 03:29:18 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 3FA5B3A6A6E for ; Thu, 16 Apr 2009 03:29:18 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B39F963B226; Thu, 16 Apr 2009 10:30:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 7EA1B63B204 for ; Thu, 16 Apr 2009 10:30:26 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 9FB97C4BB1; Thu, 16 Apr 2009 20:30:24 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id AB234C4AFF; Thu, 16 Apr 2009 20:30:18 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 3C6ACA4F54; Thu, 16 Apr 2009 20:30:18 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 3BED7A4F51; Thu, 16 Apr 2009 20:30:18 +1000 (EST) Date: Thu, 16 Apr 2009 20:30:18 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 16 Apr 2009, Peter Gutmann wrote: > >http://tools.ietf.org/html/draft-miller-secsh-compression-delayed-00 > > Hmm, why not just apply it only to the data packets? The random > non-data- related messages exchanged (again, mostly high-entropy > binary blobs) aren't going to compress much (if at all), and will only > have the effect of messing up the compression by polluting the source > statistics. With data-payload-only compression it'd be much cleaner > and easier to handle, just run the compressor over the data-packet > payload and leave everything else as is. Since we are expressing wishes for the transport protocol, mine is a per-packet compression flag :) -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:38: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 690D33A6DF7 for ; Thu, 16 Apr 2009 03:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 SInzMT923zAu for ; Thu, 16 Apr 2009 03:38:40 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8DA5D3A6D1A for ; Thu, 16 Apr 2009 03:38:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4B3AD63B214; Thu, 16 Apr 2009 10:39:44 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 76EA263B146 for ; Thu, 16 Apr 2009 10:39:40 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id 3CDC0C4CDA; Thu, 16 Apr 2009 20:39:38 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id 1669EC4B69; Thu, 16 Apr 2009 20:39:32 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 982FFA4F54; Thu, 16 Apr 2009 20:39:31 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 9611AA4F51; Thu, 16 Apr 2009 20:39:31 +1000 (EST) Date: Thu, 16 Apr 2009 20:39:31 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 16 Apr 2009, Peter Gutmann wrote: > Nicolas Williams writes: > > > When a KEXINIT is received that has a non-zero value in the KEXINIT > > reserved uint32 field, then the receiver MUST ignore both, the > > reserved uint32 field and any additional bytes in the packet beyond > > it. > > I'm not sure that this length-extension will work. The spec has always said > that the packet ends at the reserved field, but this would change it to say > that it can now continue more or less arbitrarily beyond this point. What > will existing implementations do if they see garbage beyond this point? OpenSSH will treat additional data at the end of a kex packet as a fatal error. It ignores unknown values of the "reserved" field though, so it could be used to signal that additional data follows in a different packet, or that the failure of a kex method is non-terminating. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:40:32 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 E4EC83A6D40 for ; Thu, 16 Apr 2009 03:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 cAZB7o5Pv7fe for ; Thu, 16 Apr 2009 03:40:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id CBBBF3A69B0 for ; Thu, 16 Apr 2009 03:40:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2F19463B18C; Thu, 16 Apr 2009 10:41:42 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from natsu.mindrot.org (natsu.mindrot.org [116.66.166.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id A549163B1C6 for ; Thu, 16 Apr 2009 10:41:40 +0000 (UTC) Received: by natsu.mindrot.org (Postfix, from userid 506) id A7468C4BB1; Thu, 16 Apr 2009 20:41:38 +1000 (EST) Received: from fuyu.mindrot.org (fuyu.mindrot.org [203.217.30.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "fuyu.mindrot.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by natsu.mindrot.org (Postfix) with ESMTPS id C9836C4AFF; Thu, 16 Apr 2009 20:41:32 +1000 (EST) Received: by fuyu.mindrot.org (Postfix, from userid 1000) id 5A36EA4F54; Thu, 16 Apr 2009 20:41:32 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by fuyu.mindrot.org (Postfix) with ESMTP id 59A27A4F51; Thu, 16 Apr 2009 20:41:32 +1000 (EST) Date: Thu, 16 Apr 2009 20:41:32 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904160756.DAA07579@Sparkle.Rodents-Montreal.ORG> Message-ID: References: <200904160756.DAA07579@Sparkle.Rodents-Montreal.ORG> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, 16 Apr 2009, der Mouse wrote: > >> Avoiding the attack surface presented by compression libraries > >> before authentication of the user. > > That strikes me as a desirable end. > > But the I-D I saw named upthread doesn't look like a good way to do it. > When the server starts compressing is well-defined, but the point in > the client->server data stream at which the client starts compressing > is, from the point of view of the server, ill-defined; the only way I > see to make it well-defined as the algorithm is defined is for the > client to never send anything, even IGNORE or other such messages, > between the time it sends a packet which could provoke a > USERAUTH_SUCCESS response and the time it receives some kind of > response to it. However, the spec does not specify anything of the > sort - leaving, I believe, this ill-defined. Yes, the timing of the first compressed packet is strictly indeterminate from the view of the server. The PuTTY people mentioned this some time back and suggested an extension mechanism to signal "the next packet is the first compressed one" (among other things), but the discussion fizzled. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 03:50: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 CBA0C3A6D24 for ; Thu, 16 Apr 2009 03:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 BDajTfqYtOJN for ; Thu, 16 Apr 2009 03:50:10 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id DB1C03A6F47 for ; Thu, 16 Apr 2009 03:50:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 627FE63B1F5; Thu, 16 Apr 2009 10:51:16 +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 B2B4E63B146 for ; Thu, 16 Apr 2009 10:51:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C760D1705B3; Thu, 16 Apr 2009 22:51:11 +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 kdUzc4qEPooM; Thu, 16 Apr 2009 22:51:11 +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 A7B931704E5; Thu, 16 Apr 2009 22:51:09 +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 22EF01DE4001; Thu, 16 Apr 2009 22:51:04 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LuPBP-0004CU-VS; Thu, 16 Apr 2009 22:51:04 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904160756.DAA07579@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Thu, 16 Apr 2009 22:51:03 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: >That makes sense to me (and seems well-defined, at least once you specify >precisely what "data packets" are, presumably SSH_MSG_CHANNEL_DATA, maybe >SSH_MSG_CHANNEL_EXTENDED_DATA, possibly a few others such as >SSH_MSG_CHANNEL_WINDOW_ADJUST). I may try implementing it. Yup, I was thinking specifically of CHANNEL_DATA and EXTENDED_DATA, and just the payload, not the header. >There are a lot of non-data messages that are full of uint32 fields that >typically have at least 3/4 of their bits zero. Some even use a 32-bit field >to carry one bit of information. Compressing these is valuable from the point >of view of providing higher-entropy data as the cleartext to the encryption >algorithm and therefore making it harder to attack. Uhh, so breaking AES is going to be possible if the content is uncompressed but not if it's compressed? :-). That's a pretty theoretical objection... In terms of compression, I'm not so sure that compressing the headers is a good idea. If you look at the Calgary compression corpus the least- compressible file in there is 'geo', which consists of lots of 32-bit ints with high bits zero. The reason for this is that most context-based compressors are really bad at modelling counting events (every n-th byte zero, that sort of thing), there are some special-case ones like DMC that handle this a bit better but that has some other problems that make it impractical, and I'm sure everyone else on the list has gone to sleep by now. Without running some tests it's hard to say what the effect will be, but I suspect it's not going to be quite as good as expected. It could also be rather situation-specific, for example if you're using SSH for secure logging then having the nice compressible stream of text records periodically broken up by binary blobs probably isn't a good idea. Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 05:26:39 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 E87D83A68B3 for ; Thu, 16 Apr 2009 05:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 R-9APlod5viN for ; Thu, 16 Apr 2009 05:26:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E0A9C3A679C for ; Thu, 16 Apr 2009 05:26:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0B1FD63B16E; Thu, 16 Apr 2009 12:27:43 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 150D463B154 for ; Thu, 16 Apr 2009 12:27:38 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GCRTrc027294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 08:27:30 -0400 (EDT) Date: Thu, 16 Apr 2009 08:27:27 -0400 From: Jeffrey Hutzelman To: tri@ssh.com, =?UTF-8?Q?Niels_M=C3=B6ller?= cc: der Mouse , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> In-Reply-To: <49E6FBD3.4040601@ssh.com> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <49E6FBD3.4040601@ssh.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 16, 2009 12:35:15 PM +0300 "Timo J. Rinne"=20 wrote: > Niels M=C3=B6ller wrote: >>> b) Allow a MAC algorithm to depend on encrpytion algorithm properties, >>> in the way that keyex algorithms depend on properties of host key >>> algorithms. This means that such an algorithm can be considered >>> only if the selected encryption algorithm has whatever property it >>> depends on. Then specify a single do-nothing MAC algorithm which >>> depends on AEAD encrpytion algorithm. >> >> This makes sense to me. I'd prefer this option, then. The name could >> be "none-if-aead". > > I must say I really hate this one. Instead of one simply defined "magic" > cipher algorithm name that would have, if selected, a side effect of > abolishing MAC, we would have a "magic" MAC name with much more > complicated interdependency to cipher list. > > To make it even more clear, the cipher name for aead could me something > like "aes128-aead-nomac". Then if someone likes to implement aead with > additional mac (I don't know why anyone would do that) then > "aes128-aead@foo.bar" kind of name could be used. The problem is, it's not _one_ simply defined "magic" algorithm. It's an=20 arbitrarily large number of them. But if we're going to go with Nico's "simpler" proposal, we need to address = the question Niels brought up -- does selecting an AEAD type mean we don't=20 do MAC selection at all, or does it mean we do MAC selection and then don't = actually do anything with the resulting MAC? The question is important because it controls what happens when an AEAD=20 algorithm is selected but there is no mutually-supported MAC algorithm.=20 One answer is simpler to implement, because it doesn't actually change the=20 selection algorithm at all, but the other provides more interoperability.=20 And, Niels brings up a third possibility of somehow noticing when only an=20 AEAD encryption algorithm will work and filtering out all of the others,=20 which seems really complicated to me. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 06:52: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 85DBE3A684F for ; Thu, 16 Apr 2009 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 Ft3y9Ek44BUC for ; Thu, 16 Apr 2009 06:52:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 89C5E3A6921 for ; Thu, 16 Apr 2009 06:52:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5DA2463B1C6; Thu, 16 Apr 2009 13:53:56 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-4.cisco.com", Issuer "Cisco SSCA" (not verified)) by mail.netbsd.org (Postfix) with ESMTPS id E550563B1A5 for ; Thu, 16 Apr 2009 13:53:53 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208";a="33908095" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 16 Apr 2009 12:44:22 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3GCiMJT015695; Thu, 16 Apr 2009 05:44:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3GCiM1D027975; Thu, 16 Apr 2009 12:44:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 05:44:22 -0700 Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 05:44:21 -0700 Cc: ietf-ssh@netbsd.org, Tero Kivinen , sommerfeld@sun.com, "Chris Lonvick (clonvick)" , ylo@ssh.com, "Kevin M. Igoe" , jasolin@orion.ncsc.mil, Pasi Eronen Message-Id: <034620B2-6B85-40AE-9297-367F0440CF3D@cisco.com> From: David McGrew To: Tim Polk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: applying AES-GCM to secure shell: proposed "tweak" (fwd) Date: Thu, 16 Apr 2009 05:44:19 -0700 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Apr 2009 12:44:21.0706 (UTC) FILETIME=[10BBFAA0:01C9BE91] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7222; t=1239885862; x=1240749862; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20applying=20AES-GCM=20to=20secure=20shel l=3A=20proposed=20=22tweak=22=20(fwd) |Sender:=20; bh=cgP3rhcbU7022Vfz0ZyI4qxiU2mfiNeRu7yYMau0j8k=; b=Vd++GdGPD4TsNqXtbLIGkGJDNY9+4ZyVTtchtnK+9dUrHjgf6zHvbTGTyK 35Q01i/n32XdBxBD9RQ6AHXnmXcIyzyygJPaHJIGn4OlpBQmUGQIJVnRQQVq /Fr65CSFWg; Authentication-Results: sj-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Hi Tim, this email very nicely outlines the situation; some comments inline: > ---------- Forwarded message ---------- > Date: Wed, 8 Apr 2009 09:02:00 -0400 > From: Tim Polk > To: ietf-ssh@netbsd.org > Cc: Tero Kivinen , Bill Sommerfeld > , > Chris Lonvick , ylo@ssh.com, > "Igoe, Kevin M." , > Jerome A. Solinas , > " Eronen" > Subject: applying AES-GCM to secure shell: proposed "tweak" > > Folks, > > The IESG is currently considering publication of draft-igoe-secsh-aes- > gcm-01, "AES Galois Counter Mode for the Secure Shell Transport Layer > Protocol", as an Informational RFC. The draft specifies the > application of the Authenticated Encryption with Associated Data > (AEAD) block cipher mode AES Galois/Counter Mode to provide both > confidentiality and data integrity for SSH. (See RFC 5116, "An > Interface and Algorithms for Authenticated Encryption", for a general > look at AEAD algorithms and NIST Special Publication 800-38D for the > specification of the GCM mode; see URLs below.) > > The draft was designed to minimize the changes to RFC 4253 (the SSH > Transport Layer Protocol), so it encrypts the whole SSH binary packet, > including the packet_length field. > > However, AEAD decryption as defined in both RFC 5116 and SP 800-38D > takes the ciphertext as input, and returns either (1) the plaintext if > the authentication succeeds or (2) failure. The ciphertext here is an > octet string of known length, not an ubounded stream. > > Since the packet_length field is also encrypted, SSH cannot determine > the ciphertext boundary before passing the data to AEAD decryption. > (This differs from current SSH encryption modes where the data is > first decrypted, then the packet length field is parsed, and finally > the MAC is verified.) > > Two solutions have been proposed: (1) explicitly allowing "partial > decryption" so that an implementation can recover the packet_length > without authenticating the data; or (2) sending the packet_length > unencrypted so that it is always available. > > The first solution requires less security analysis about SSH, but more > analysis about the AEAD algorithm. The exposure of intermediate values > in AES GCM would require review, and it is inconsistent with RFC > 5116. Even if this solution is determined to be secure for AES GCM, > this might not apply to other AEAD algorithms (where returning > plaintext fragments before authentication may not be even possible, or > may not be secure). In a more parochial concern, inconsistency with SP > 800-38D means that current validation processes (i.e. NIST's FIPS > 140-based Cryptographic Module Validation Program [CMVP]) would need > to be revised, as well as SP 800-38D, to permit use of this protocol > with validated modules. > > The second solution (sending packet_length unencrypted) has a number > of desirable properties: it conforms to RFC 5116 so the design should > apply to any AEAD algorithm, and it is consistent with the algorithm > specification (NIST SP 800-38D). It does require a change to the > padding calculations: since the plaintext for encryption excludes the > packet_length, the concatenation of the 'padding length', 'payload', > and 'random padding' MUST be a multiple of the cipher block size. > (This modifies a requirement from Section 6 of RFC 4253.) Since this > calculation is algorithm specific anyway, it is hoped this would not > be an issue. As you might have guessed, I strongly prefer this > solution. However, we are concerned about making such a change > without ensuring that the security implications have been thoroughly > reviewed. I also strongly prefer this solution, because partial decryption is counter to "authenticated encryption". A lot of work has been done in the theoretical community and in standards groups in the direction of authenticated encryption, and it makes more sense to position SSH to benefit from that line work in the future. > > The SSHv1 protocol revealed the exact plaintext length, which is > clearly undesirable in many situations (see e.g. link below). In > SSHv2, the packet length includes the random padding, so sending it > unencrypted does not reveal the exact the plaintext length. Also, in > many cases the packet length can be inferred from the data stream > (e.g. TCP segment lengths). In applications where there is some fear > that the packet lengths might reveal sensitive information, the use of > random padding probably provides a much more effective countermeasure > than encrypting the packet_length. > > So, it seems that encryption of the packet_length field would be of > little practical use, and might lead to a false sense of security. As > a consequence, we hypothesize that sending packet_length in the clear > would not negatively impact the security of the protocol. > > Before moving forward with this protocol using either of the proposed > solutions, we would appreciate feedback from this mailing list. > Questions to consider: > > (1) does the exposure of the ssh packet length have significant > security implications for ssh itself? > > (2) were applications that rely on ssh for security designed to take > advantage of the encrypted packet length? > > (3) does the change in padding length calculation (caused by excluding > the packet_length from the ciphertext) impose a significant impediment > to migrating existing implementations? > This message was forwarded to me (I'm not on the ssh list) so if security issues have been raised in further emails, I haven't seen them. (If someone perceives a significant security implication in SSH itself, I would like to review it; please forward.) Reading over the security considerations of RFC 4251, there are descriptions of various security issues due to the use of CBC. I also noticed that it does not reference "Security Flaws Induced by CBC Padding", Vaudenay, EUROCRYPT'02, http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps , which is yet another security issue that can occur due to unauthenticated CBC (and SSH as it is currently defined requires that the first CBC block be decrypted prior to the MAC verification step). These problems would not be present if we avoid partial- decryption and stick with authenticated encryption (and AE is what Vaudenay recommends in Section 7 of the above reference, FWIW). best regards, David > Thanks, > > Tim Polk > (Security co-AD and document sponsor) > > P.S. I've tried to contact as many of the usual suspects as > possible, but I am sure I have > missed some folks. Please forward this to anyone I've left off > distribution that might > have an interest!] > > References: > > http: //tools.ietf.org/html/rfc5116 > http: //tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01 > http: //csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf > http: //www.openwall.com/advisories/OW-003-ssh-traffic-analysis/ From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:19: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 56C683A6F30 for ; Thu, 16 Apr 2009 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.876 X-Spam-Level: X-Spam-Status: No, score=-5.876 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd8eoce7QFWq for ; Thu, 16 Apr 2009 07:19:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 90E0D3A6D74 for ; Thu, 16 Apr 2009 07:19:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 09AB463B1E2; Thu, 16 Apr 2009 14:21:00 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 CBE3263B180 for ; Thu, 16 Apr 2009 14:20:56 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GEKkGQ003356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:20:47 -0400 (EDT) Date: Thu, 16 Apr 2009 10:20:46 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , =?UTF-8?Q?Niels_M=C3=B6ller?= cc: der Mouse , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: In-Reply-To: <20090416140435.GR1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 16, 2009 09:04:35 AM -0500 Nicolas Williams wrote: > This is a separate issue. Remove AEAD and you don't interop. Add AEAD > with my rule and you still don't interop. To improve the situation we > need to twist the KEXINIT abstraction a bit more (no objections from > me): IF a non-AEAD cipher is chosen AND there was no common MAC AND > there was a common AEAD cipher THEN re-compute the cipher selection > ignoring all non-AEAD ciphers. Ugh. This is starting to get complicated. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:21: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 A5A293A6D0D for ; Thu, 16 Apr 2009 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 2RI6401xjJU1 for ; Thu, 16 Apr 2009 07:21:41 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E310D3A6C0C for ; Thu, 16 Apr 2009 07:21:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 76FD363B1B4; Thu, 16 Apr 2009 14:22:51 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from smtp7.xenetic.net (smtp7.xenetic.net [80.88.176.189]) (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 92B0763B180 for ; Thu, 16 Apr 2009 14:22:48 +0000 (UTC) Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp7.xenetic.net (8.14.3/8.14.3) with ESMTP id n3GEMfmt024847; Thu, 16 Apr 2009 17:22:42 +0300 Received: from [10.1.254.253] ([10.1.254.253]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 17:22:41 +0300 Message-ID: <49E73F30.4060702@ssh.com> Date: Thu, 16 Apr 2009 17:22:40 +0300 From: "Timo J. Rinne" Reply-To: tri@ssh.com Organization: SSH Communications Security Corp. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jeffrey Hutzelman CC: =?UTF-8?B?TmllbHMgTcO2bGxlcg==?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <49E6FBD3.4040601@ssh.com> <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> In-Reply-To: <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Apr 2009 14:22:41.0557 (UTC) FILETIME=[CD51CC50:01C9BE9E] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4,1.2.40,4.0.166 definitions=2009-04-16_08:2009-04-15,2009-04-16,2009-04-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904160090 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list Jeffrey Hutzelman wrote: > --On Thursday, April 16, 2009 12:35:15 PM +0300 "Timo J. Rinne" > wrote: > >> Niels Möller wrote: >>>> b) Allow a MAC algorithm to depend on encrpytion algorithm properties, >>>> in the way that keyex algorithms depend on properties of host key >>>> algorithms. This means that such an algorithm can be considered >>>> only if the selected encryption algorithm has whatever property it >>>> depends on. Then specify a single do-nothing MAC algorithm which >>>> depends on AEAD encrpytion algorithm. >>> >>> This makes sense to me. I'd prefer this option, then. The name could >>> be "none-if-aead". >> >> I must say I really hate this one. Instead of one simply defined "magic" >> cipher algorithm name that would have, if selected, a side effect of >> abolishing MAC, we would have a "magic" MAC name with much more >> complicated interdependency to cipher list. >> >> To make it even more clear, the cipher name for aead could me something >> like "aes128-aead-nomac". Then if someone likes to implement aead with >> additional mac (I don't know why anyone would do that) then >> "aes128-aead@foo.bar" kind of name could be used. > > The problem is, it's not _one_ simply defined "magic" algorithm. It's > an arbitrarily large number of them. > > But if we're going to go with Nico's "simpler" proposal, we need to > address the question Niels brought up -- does selecting an AEAD type > mean we don't do MAC selection at all, or does it mean we do MAC > selection and then don't actually do anything with the resulting MAC? > > The question is important because it controls what happens when an AEAD > algorithm is selected but there is no mutually-supported MAC algorithm. > One answer is simpler to implement, because it doesn't actually change > the selection algorithm at all, but the other provides more > interoperability. And, Niels brings up a third possibility of somehow > noticing when only an AEAD encryption algorithm will work and filtering > out all of the others, which seems really complicated to me. I can live with both options 1 and 2. I agree that changing kex algorithm selection logic would be more complicated than requiring common mac to be found even in the situations where it's eventually ignored. I'd be inclined towards the simpler option. Additional option might be introducing a mac name (could actually be used in ciphers and compressions too) that would be "fail-if-used". That would be put to the tail if mac list if aead modes are used as possible ciphers. In case some other mac is selected with aead cipher, it's simply dropped, if "fail-if-used" is selected with aead, it's dropped as well. In case "fail-if-used" mac gets selected with a traditional cipher it will fail in some implementation dependant way. -- Timo J. Rinne Valimotie 17 +358 20 500 7000 T Chief Technology Officer FIN-00380 Helsinki +358 20 500 7397 F SSH Communications Security Corp. Finland http://www.ssh.com From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:26:57 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 756443A6D5D for ; Thu, 16 Apr 2009 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.187, 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 bNXFxrExIY2C for ; Thu, 16 Apr 2009 07:26:56 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 4D5763A6C2B for ; Thu, 16 Apr 2009 07:26:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7123763B174; Thu, 16 Apr 2009 14:28:02 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id 7EC4763B14B for ; Thu, 16 Apr 2009 14:27:59 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GERxNJ003368 for ; Thu, 16 Apr 2009 14:27: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 n3GERw4d057413 for ; Thu, 16 Apr 2009 08:27:58 -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 n3GEB2kD012157; Thu, 16 Apr 2009 09:11:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GEB1rY012156; Thu, 16 Apr 2009 09:11:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 09:11:01 -0500 From: Nicolas Williams To: Peter Gutmann Cc: mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416141101.GS1500@Sun.COM> References: <20090415220515.GN1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 04:15:33PM +1200, Peter Gutmann wrote: > Nicolas Williams writes: > > >I don't recall where the attack is described. > > It's in a conference paper that hasn't been published yet, to appear at the > IEEE Oakland conference in... May, I think. > > [Pause] > > Yup, see http://oakland09.cs.virginia.edu/papers.html. Thanks. > >Briefly: an active attacker replaces what he/she knows to be an encrypted > >packet length with bytes that he/she knows correspond to an encrypted > >password, then after that sends the remainder of the packet (possibly > >garbage) one byte/block at a time. > > It's interesting to note here that there have been a number of attacks (of > which this is the latest) on encrypted lengths, but none on plaintext lengths > as used by TLS. In other words the "more secure" option used by SSH is > actually less secure than the "less secure" option of not encrypting, the > cause being the unnecessary complexity of processing that this introduces (see > my earlier posts in this thread, and I still owe people some replies for one > or two of those, sorry). Well, sortof. TLS says it does not protect against traffic analysis, therefore we consider traffic analysis attacks out of scope -- there are no traffic analysis attacks against TLS by definition. That's not exactly a fair comparison. That said, I think encrypted packet lengths are more trouble than they're worth and don't actually suffice for protection against traffic analysis, which makes you wonder what the heck was ever the point. For example, say I'm prompted for a password, echo-off, in a pty session, and my client sends keystrokes one at a time. Well, any eavesdropper can notice that pattern and determine the length of my password. The server can detect this and defeat this by adding IGNORE messages to emulate echo-on, and the client can add random padding or else gather more keystrokes before sending them -- but all of this is not-crypto and if it's needed it's needed because encrypting the packet length was insufficient. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:28: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 35BBB3A6F3B for ; Thu, 16 Apr 2009 07:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhPTjOAXETED for ; Thu, 16 Apr 2009 07:28:01 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 2458A3A6D50 for ; Thu, 16 Apr 2009 07:28:01 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E6AD363B154; Thu, 16 Apr 2009 14:29:10 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 829A363B14B for ; Thu, 16 Apr 2009 14:29:09 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GET9xx012401 for ; Thu, 16 Apr 2009 14:29:09 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 n3GET8Jn058284 for ; Thu, 16 Apr 2009 08:29:08 -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 n3GE4hA4012151; Thu, 16 Apr 2009 09:04:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GE4ZiZ012150; Thu, 16 Apr 2009 09:04:35 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 09:04:35 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416140435.GR1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 10:22:03AM +0200, Niels Möller wrote: > Nicolas Williams writes: > > But not simpler than my proposal: > > > > IF an AEAD cipher is selected THEN no MAC alg is selected (since the > > cipher provides integrity protection all by its lonesome). > > To be precise, does this mean that the mac-list is ignored, or that > the *result* of that selection is ignored? Consider the following > advertised lists: > > Client: enc="aead", mac="hmac-sha1" > Server: enc="aead", mac="hmac-md5" > > Should the algorithm selection succeed, settling on aead and no > additional mac, or fail because there's no common mac? The former. > Or to make it more complicated, what should be the result of: > > Client: enc="3des-cbc,aead", mac="hmac-sha1" > Server: enc="3des-cbc,aead", mac="hmac-md5" > > We can either fail, since is 3des-cbc selected for encryption, but > there's no common mac, or succeed if we notice that there's no common > mac, and then filter out all non-AEAD options for encryption. This is a separate issue. Remove AEAD and you don't interop. Add AEAD with my rule and you still don't interop. To improve the situation we need to twist the KEXINIT abstraction a bit more (no objections from me): IF a non-AEAD cipher is chosen AND there was no common MAC AND there was a common AEAD cipher THEN re-compute the cipher selection ignoring all non-AEAD ciphers. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:36:06 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 36A263A6822 for ; Thu, 16 Apr 2009 07:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 8Nd12Ws4dLoH for ; Thu, 16 Apr 2009 07:36:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id E589828C1FF for ; Thu, 16 Apr 2009 07:36:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C01D563B165; Thu, 16 Apr 2009 14:36:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 F1BB363B147 for ; Thu, 16 Apr 2009 14:36:56 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GEaoLg003968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:36:51 -0400 (EDT) Date: Thu, 16 Apr 2009 10:36:50 -0400 From: Jeffrey Hutzelman To: tri@ssh.com cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , der Mouse , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <55FB5E58C5F41F7BCD0AAE7C@atlantis.pc.cs.cmu.edu> In-Reply-To: <49E73F30.4060702@ssh.com> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <49E6FBD3.4040601@ssh.com> <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> <49E73F30.4060702@ssh.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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 16, 2009 05:22:40 PM +0300 "Timo J. Rinne" wrote: > Additional option might be introducing a mac name (could actually be used > in ciphers and compressions too) that would be "fail-if-used". That would > be put to the tail if mac list if aead modes are used as possible > ciphers. In case some other mac is selected with aead cipher, it's > simply dropped, if "fail-if-used" is selected with aead, it's dropped as > well. In case "fail-if-used" mac gets selected with a traditional cipher > it will fail in some implementation dependant way. That's an interesting approach. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:49: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 AF7F83A6F72 for ; Thu, 16 Apr 2009 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 T43XMmj1soKN for ; Thu, 16 Apr 2009 07:49:27 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C59ED3A6C3C for ; Thu, 16 Apr 2009 07:49:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 90C5863B146; Thu, 16 Apr 2009 14:50:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) (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 1506E63B139 for ; Thu, 16 Apr 2009 14:50:15 +0000 (UTC) Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GEoAwZ004555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:50:10 -0400 (EDT) Date: Thu, 16 Apr 2009 10:50:10 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , der Mouse , ietf-ssh@NetBSD.org, jhutz@cmu.edu Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> In-Reply-To: <20090416143030.GX1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <20090416143030.GX1500@Sun.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.201.16 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list --On Thursday, April 16, 2009 09:30:30 AM -0500 Nicolas Williams wrote: > On Thu, Apr 16, 2009 at 10:20:46AM -0400, Jeffrey Hutzelman wrote: >> --On Thursday, April 16, 2009 09:04:35 AM -0500 Nicolas Williams >> wrote: >> >> > This is a separate issue. Remove AEAD and you don't interop. Add AEAD >> > with my rule and you still don't interop. To improve the situation we >> > need to twist the KEXINIT abstraction a bit more (no objections from >> > me): IF a non-AEAD cipher is chosen AND there was no common MAC AND >> > there was a common AEAD cipher THEN re-compute the cipher selection >> > ignoring all non-AEAD ciphers. >> >> Ugh. This is starting to get complicated. > > No, it's not. I'm perfectly happy to have the problem that Niels > pointed out. Yes, it is. The twist you describe is complicated. It's a funny special case. What's going to happen when we have another funny special case? From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 07:53: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 D4ACC3A6F61 for ; Thu, 16 Apr 2009 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.185, 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 BdMmoQTlHkDp for ; Thu, 16 Apr 2009 07:53:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C146F3A6C3C for ; Thu, 16 Apr 2009 07:53:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B893F63B12D; Thu, 16 Apr 2009 14:54:57 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id 8879763B139 for ; Thu, 16 Apr 2009 14:54:56 +0000 (UTC) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GEsukN008947 for ; Thu, 16 Apr 2009 14:54:56 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 n3GEstdh012793 for ; Thu, 16 Apr 2009 08:54:55 -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 n3GEUUmC012215; Thu, 16 Apr 2009 09:30:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GEUUPG012214; Thu, 16 Apr 2009 09:30:30 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 09:30:30 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Niels =?iso-8859-1?Q?M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416143030.GX1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 10:20:46AM -0400, Jeffrey Hutzelman wrote: > --On Thursday, April 16, 2009 09:04:35 AM -0500 Nicolas Williams > wrote: > > >This is a separate issue. Remove AEAD and you don't interop. Add AEAD > >with my rule and you still don't interop. To improve the situation we > >need to twist the KEXINIT abstraction a bit more (no objections from > >me): IF a non-AEAD cipher is chosen AND there was no common MAC AND > >there was a common AEAD cipher THEN re-compute the cipher selection > >ignoring all non-AEAD ciphers. > > Ugh. This is starting to get complicated. No, it's not. I'm perfectly happy to have the problem that Niels pointed out. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 08:14:38 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 7F3473A69BC for ; Thu, 16 Apr 2009 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=0.184, 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 eQrWX3vDuwxo for ; Thu, 16 Apr 2009 08:14:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 9719D3A686C for ; Thu, 16 Apr 2009 08:14:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CEFD163B1E3; Thu, 16 Apr 2009 15:15:46 +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 1358063B1A5 for ; Thu, 16 Apr 2009 15:15:38 +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 n3GFFcO6011070 for ; Thu, 16 Apr 2009 15:15:38 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 n3GFFbZB029674 for ; Thu, 16 Apr 2009 09:15:37 -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 n3GEpC5u012263; Thu, 16 Apr 2009 09:51:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GEpC42012262; Thu, 16 Apr 2009 09:51:12 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 09:51:12 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Niels =?iso-8859-1?Q?M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416145111.GA1500@Sun.COM> References: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <20090416143030.GX1500@Sun.COM> <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 10:50:10AM -0400, Jeffrey Hutzelman wrote: > --On Thursday, April 16, 2009 09:30:30 AM -0500 Nicolas Williams > wrote: > > >On Thu, Apr 16, 2009 at 10:20:46AM -0400, Jeffrey Hutzelman wrote: > >>--On Thursday, April 16, 2009 09:04:35 AM -0500 Nicolas Williams > >> wrote: > >> > >>> This is a separate issue. Remove AEAD and you don't interop. Add AEAD > >>> with my rule and you still don't interop. To improve the situation we > >>> need to twist the KEXINIT abstraction a bit more (no objections from > >>> me): IF a non-AEAD cipher is chosen AND there was no common MAC AND > >>> there was a common AEAD cipher THEN re-compute the cipher selection > >>> ignoring all non-AEAD ciphers. > >> > >>Ugh. This is starting to get complicated. > > > >No, it's not. I'm perfectly happy to have the problem that Niels > >pointed out. > > Yes, it is. The twist you describe is complicated. It's a funny special > case. What's going to happen when we have another funny special case? Like I said: I'm happy to have that problem. But also, we are not likely to have a new funny special case soon enough that we can't, in the interim work out a generic KEX extensibility scheme. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 08:22: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 EEA563A6D72 for ; Thu, 16 Apr 2009 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.48 X-Spam-Level: X-Spam-Status: No, score=-9.48 tagged_above=-999 required=5 tests=[AWL=0.508, 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 yOsRGTZH8Gmi for ; Thu, 16 Apr 2009 08:22:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id B47783A6F56 for ; Thu, 16 Apr 2009 08:22:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C070A63B12B; Thu, 16 Apr 2009 15:23:07 +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 8A05163B139 for ; Thu, 16 Apr 2009 15:23:04 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA09381; Thu, 16 Apr 2009 11:23:03 -0400 (EDT) From: der Mouse Message-Id: <200904161523.LAA09381@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: Thu, 16 Apr 2009 11:13:01 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> To improve the situation we need to twist the KEXINIT abstraction a >> bit more [...] IF a non-AEAD cipher is chosen AND there was no >> common MAC AND there was a common AEAD cipher THEN re-compute the >> cipher selection ignoring all non-AEAD ciphers. This rule interacts very badly with the implementation of any other encryption algorithm that similarly wants to ignore MACs, especially if it defines an analogous rule. > Ugh. This is starting to get complicated. Indeed. My "next special case" has shown up already and the first one hasn't even been settled yet. I stand by my stance that this approach will rapidly turn kex into an incomprehensible (and, of course, unmaintainable) mess of cross-linked dependencies. For implementers who are determined to do it anyway - don't forget, when deciding what to implement, to also think about interop with implementations that haven't heard of, or decided not to implement, whatever you settle on. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 08:41:07 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 A96AF3A6915 for ; Thu, 16 Apr 2009 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.493 X-Spam-Level: X-Spam-Status: No, score=-9.493 tagged_above=-999 required=5 tests=[AWL=0.495, 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 1TsdR5cO+UBp for ; Thu, 16 Apr 2009 08:41:06 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 009AD3A6D5B for ; Thu, 16 Apr 2009 08:40:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A2EB763B1E8; Thu, 16 Apr 2009 15:41: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 3D93B63B14A for ; Thu, 16 Apr 2009 15:41:46 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA09507; Thu, 16 Apr 2009 11:41:41 -0400 (EDT) From: der Mouse Message-Id: <200904161541.LAA09507@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: Thu, 16 Apr 2009 11:26:18 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> There are a lot of non-data messages that are full of uint32 fields >> that typically have at least 3/4 of their bits zero. Some even use >> a 32-bit field to carry one bit of information. Compressing these >> is valuable from the point of view of providing higher-entropy data >> as the cleartext to the encryption algorithm and therefore making it >> harder to attack. > Uhh, so breaking AES is going to be possible if the content is > uncompressed but not if it's compressed? :-) Perhaps. As a cryptographer I'm strictly a dilettante, but even I know that the lower the entropy of the plaintext, the easier it is to attack an encryption algorithm. Knowing that most of the bits are zero could be the edge that makes the difference between working and failing for some attack - especially since you mostly know which ones they are (the high-order bits of most uint32s). > That's a pretty theoretical objection... At the moment, yes. But attacks only get better.... > In terms of compression, I'm not so sure that compressing the headers > is a good idea. I'm not sure either. I suspect the right thing to do is to implement various alternatives, instrument them all, and see what happens in real use. (Actually, I'd be tempted to implement _all_ the alternatives and record the results: that is, on the sending end, run all these different compression algorithms and record the statistics - what actually gets sent on the wire can be whichever one is most convenient, since it's the statistics of the cleartext that are of interest.) I have my guesses, of course, and you clearly have some of your own, but nothing beats actual measurements. > It could also be rather situation-specific, for example if you're > using SSH for secure logging then having the nice compressible stream > of text records periodically broken up by binary blobs probably isn't > a good idea. Perhaps - but, since consecutive log records are usually mostly independent, it probably won't do too much damage, either. Yes, it could well be situation-specific. If I do the "do them all and instrument" thing, I may leave the instrumentation infrastructure in place in the shipped version and provide a way for people to turn it on and collect the data to figure otu which form of compression works best for their particular application. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 08:54:14 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 AF6193A6F86 for ; Thu, 16 Apr 2009 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=0.184, 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 LcpcCuX-fJLj for ; Thu, 16 Apr 2009 08:54:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id C4A1E3A6F81 for ; Thu, 16 Apr 2009 08:54:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 90A7063B1C0; Thu, 16 Apr 2009 15:55:19 +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 9F5D063B180 for ; Thu, 16 Apr 2009 15:55:17 +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 n3GFtHH0026413 for ; Thu, 16 Apr 2009 15:55:17 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 n3GFtGo6017101 for ; Thu, 16 Apr 2009 09:55:16 -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 n3GFjoMw012356; Thu, 16 Apr 2009 10:45:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GFjokU012355; Thu, 16 Apr 2009 10:45:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 10:45:50 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416154549.GH1500@Sun.COM> References: <200904161541.LAA09507@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904161541.LAA09507@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 11:26:18AM -0400, der Mouse wrote: > >> There are a lot of non-data messages that are full of uint32 fields > >> that typically have at least 3/4 of their bits zero. Some even use > >> a 32-bit field to carry one bit of information. Compressing these > >> is valuable from the point of view of providing higher-entropy data > >> as the cleartext to the encryption algorithm and therefore making it > >> harder to attack. > > Uhh, so breaking AES is going to be possible if the content is > > uncompressed but not if it's compressed? :-) > > Perhaps. As a cryptographer I'm strictly a dilettante, but even I know > that the lower the entropy of the plaintext, the easier it is to attack > an encryption algorithm. Knowing that most of the bits are zero could > be the edge that makes the difference between working and failing for > some attack - especially since you mostly know which ones they are (the > high-order bits of most uint32s). Lossless compression does not alter the amount of entropy in a message. Therefore deterministic use/non-use of compression ought to have no impact on known-plaintext attacks. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 09:06: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 789043A6CD6 for ; Thu, 16 Apr 2009 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.563 X-Spam-Level: X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=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 DvXFp87EqFFP for ; Thu, 16 Apr 2009 09:06:34 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 53F273A687F for ; Thu, 16 Apr 2009 09:06:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B361B63B180; Thu, 16 Apr 2009 16:07:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id 02DFF63B14A for ; Thu, 16 Apr 2009 16:07:37 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GG7bDF005300 for ; Thu, 16 Apr 2009 16:07:37 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 n3GG7bY2029840 for ; Thu, 16 Apr 2009 10:07:37 -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 n3GFwBor012374; Thu, 16 Apr 2009 10:58:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GFwBiI012373; Thu, 16 Apr 2009 10:58:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 10:58:11 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: KEX_OPTION (Re: applying AES-GCM to secure shell: proposed "tweak") Message-ID: <20090416155810.GK1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <200904161523.LAA09381@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904161523.LAA09381@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 11:13:01AM -0400, der Mouse wrote: > >> To improve the situation we need to twist the KEXINIT abstraction a > >> bit more [...] IF a non-AEAD cipher is chosen AND there was no > >> common MAC AND there was a common AEAD cipher THEN re-compute the > >> cipher selection ignoring all non-AEAD ciphers. > > This rule interacts very badly with the implementation of > any other encryption algorithm that similarly wants to ignore MACs, > especially if it defines an analogous rule. Surely such an encryption algorithm would be an AEAD algorithm, therefore there is no such interaction (since the rule still applies). You're making this more complicated than it has to be. > > Ugh. This is starting to get complicated. > > Indeed. My "next special case" has shown up already and the first one > hasn't even been settled yet. I stand by my stance that this approach > will rapidly turn kex into an incomprehensible (and, of course, > unmaintainable) mess of cross-linked dependencies. "Incomprehensible", no, "complex", yes. But that's what we have to work with. I don't see Jeff's proposal for a KEX_OPTION packet type as making any of this less complex now, but it is a way forward the next time we need it. Of course, Jeff's KEX_OPTION packet type needs negotiation too! Jeff proposed using the comment field of the SSH version message. But I think I will not be alone in rejecting that idea. We can only really use the reserved uint32 field for the KEX_OPTION packet type. Which means that we MUST first fix the handling of the reserved uint32 field. Which means we can only really use alg names for AEAD negotiation right now, and must also fix the reserved uint32 field now so we can use it the next time around. It's not how I'd design the protocol from scratch, y'know. It's what we've got to work with. Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 09:12: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 6B6EA3A6BC6 for ; Thu, 16 Apr 2009 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9b4UNa-nU4s for ; Thu, 16 Apr 2009 09:12:45 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 35B233A67EC for ; Thu, 16 Apr 2009 09:12:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C415963B155; Thu, 16 Apr 2009 16:13:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 660C363B10B for ; Thu, 16 Apr 2009 16:13:50 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GGDnWP028872 for ; Thu, 16 Apr 2009 16:13:49 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 n3GGDnFQ034992 for ; Thu, 16 Apr 2009 10:13:49 -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 n3GFnNnH012362; Thu, 16 Apr 2009 10:49:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GFnNA4012361; Thu, 16 Apr 2009 10:49:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 10:49:23 -0500 From: Nicolas Williams To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Jeffrey Hutzelman , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416154922.GI1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 10:07:18AM +0200, Niels Möller wrote: > Jeffrey Hutzelman writes: > > > I'd prefer not to have that particular rule. I think it would be better > > to explicitly describe a MAC algorithm which does nothing has no effect, > > and do one of these: > > [...] > > > b) Allow a MAC algorithm to depend on encrpytion algorithm properties, > > in the way that keyex algorithms depend on properties of host key > > algorithms. This means that such an algorithm can be considered > > only if the selected encryption algorithm has whatever property it > > depends on. Then specify a single do-nothing MAC algorithm which > > depends on AEAD encrpytion algorithm. > > This makes sense to me. I'd prefer this option, then. The name could > be "none-if-aead". That's fine with me too. Though I don't see how it solves this problem: Client ciphers = des3-cbc, aes-gcm MACs = hmac-md5, none-if-aead Server ciphers = des3-cbc, aes-gcm MACs = hmac-sha1, none-if-aead I.e., we still have the problem you found. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 09:16:12 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 B9E3D28C0D8 for ; Thu, 16 Apr 2009 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=0.183, 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 PQ-5frXKq5ZQ for ; Thu, 16 Apr 2009 09:16:12 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 8458F28C137 for ; Thu, 16 Apr 2009 09:16:02 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4255363B14A; Thu, 16 Apr 2009 16:17:12 +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 CAF6C63B19C for ; Thu, 16 Apr 2009 16:17:09 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GGH9ah003944 for ; Thu, 16 Apr 2009 16:17: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 n3GGH9uA039053 for ; Thu, 16 Apr 2009 10:17: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 n3GFqhRF012368; Thu, 16 Apr 2009 10:52:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GFqhHf012367; Thu, 16 Apr 2009 10:52:43 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 10:52:43 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: tri@ssh.com, Niels =?iso-8859-1?Q?M=F6ller?= , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416155242.GJ1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <49E6FBD3.4040601@ssh.com> <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63399C584C6292AFE379576B@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 08:27:27AM -0400, Jeffrey Hutzelman wrote: > But if we're going to go with Nico's "simpler" proposal, we need to address > the question Niels brought up -- does selecting an AEAD type mean we don't > do MAC selection at all, or does it mean we do MAC selection and then don't > actually do anything with the resulting MAC? > > The question is important because it controls what happens when an AEAD > algorithm is selected but there is no mutually-supported MAC algorithm. No, the question is irrelevant since it's truly obvious what to do (if AEAD cipher chosen -> no MAC negotiation takes place). The real problem is the unrelated problem that Niels found where the client and server would choose a non-AEAD cipher but have no common MAC and could have chosen an AEAD cipher. > And, Niels brings up a third possibility of somehow noticing when only an > AEAD encryption algorithm will work and filtering out all of the others, > which seems really complicated to me. See my other replies. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 11:04:40 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 34B383A6885 for ; Thu, 16 Apr 2009 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.506 X-Spam-Level: X-Spam-Status: No, score=-9.506 tagged_above=-999 required=5 tests=[AWL=0.482, 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 MLvbhQ0CJpYd for ; Thu, 16 Apr 2009 11:04:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1A0FD3A6831 for ; Thu, 16 Apr 2009 11:04:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2376763B1C3; Thu, 16 Apr 2009 18:05:44 +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 932FC63B1D5 for ; Thu, 16 Apr 2009 18:05:41 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA10250; Thu, 16 Apr 2009 14:05:40 -0400 (EDT) From: der Mouse Message-Id: <200904161805.OAA10250@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: Thu, 16 Apr 2009 11:59:37 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <20090416154549.GH1500@Sun.COM> References: <200904161541.LAA09507@Sparkle.Rodents-Montreal.ORG> <20090416154549.GH1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> Perhaps. As a cryptographer I'm strictly a dilettante, but even I >> know that the lower the entropy of the plaintext, the easier it is >> to attack an encryption algorithm. > Lossless compression does not alter the amount of entropy in a > message. True, but it does alter the entropy density (entropy per encryption block, per byte, per whatever), and that's what results in the effect I mentioned. > Therefore deterministic use/non-use of compression ought to have no > impact on known-plaintext attacks. This isn't quite what I understand "known-plaintext" to refer to. This is partial and statistical knowledge of the plaintext, whereas known-plaintext as I understand the term refers to complete knowledge. Known-plaintext in the sense I understand it, you're right: if you know the input bits, it doen't matter whether they come directly from the protocol engine or from a compression engine. (Some particular sets of cleartext bits may make some attacks easier than others, but then we're heading towards the realm of chosen plaintext.) But in the partial sense we have here, it does matter: in the extreme, consider, say, a block cipher with block size 64, and consider feeding it a stream of 64 uint32s each of which is 0 or 1, versus feeding it a single blob of 64 bits carrying the same information. In the former case, if you think maybe you know the key, it's fairly easy to check reliably, even knowing nothing about the data bits; in the latter, it's theoretically impossible to tell whether you have the right key if you don't know anything about the cleartext. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 11:19:12 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 223283A68B8 for ; Thu, 16 Apr 2009 11:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.519 X-Spam-Level: X-Spam-Status: No, score=-9.519 tagged_above=-999 required=5 tests=[AWL=0.469, 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 VY+yhdagjkLE for ; Thu, 16 Apr 2009 11:19:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 46CA03A6801 for ; Thu, 16 Apr 2009 11:19:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C1EC663B198; Thu, 16 Apr 2009 18:20:18 +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 5F55263B193 for ; Thu, 16 Apr 2009 18:20:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA10401; Thu, 16 Apr 2009 14:20:16 -0400 (EDT) From: der Mouse Message-Id: <200904161820.OAA10401@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: Thu, 16 Apr 2009 14:13:42 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: KEX_OPTION (Re: applying AES-GCM to secure shell: proposed "tweak") In-Reply-To: <20090416155810.GK1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <200904161523.LAA09381@Sparkle.Rodents-Montreal.ORG> <20090416155810.GK1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>>> IF a non-AEAD cipher is chosen AND there was no common MAC AND >>>> there was a common AEAD cipher THEN re-compute the cipher >>>> selection ignoring all non-AEAD ciphers. >> This rule interacts very badly with the implementation of any other >> encryption algorithm that similarly wants to ignore MACs, especially >> if it defines an analogous rule. > Surely such an encryption algorithm would be an AEAD algorithm, > therefore there is no such interaction (since the rule still > applies). You truly believe that, for the entire lifetime of SSHv2, nobody will ever come up with another way to roll tamper-evident-ness in with encryption (or at least won't want to use such a thing with SSHv2)? I find that...dubious, at best. > Of course, Jeff's KEX_OPTION packet type needs negotiation too! I don't see why. Send it and let it get handled or rejected. (I do not favour mollycoddling implementations that can't be bothered to implement the spec's mandate for handling packet types they don't understand. Such implementations are broken, and need to be widely shown to be, and recognized as, broken. Compatability hacks in implementations are an implementation matter, but there's no need to tie the hands of protocol design for the sake of tolerating implementation bugs, especially ones this severe.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 11:28: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 B70243A68B8 for ; Thu, 16 Apr 2009 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.180, 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 2mU25dcSTIu0 for ; Thu, 16 Apr 2009 11:28:33 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A25793A682D for ; Thu, 16 Apr 2009 11:28:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C1E2563B14E; Thu, 16 Apr 2009 18:29:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.netbsd.org (Postfix) with ESMTP id 92F0563B14B for ; Thu, 16 Apr 2009 18:29:39 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GITddW014271 for ; Thu, 16 Apr 2009 18:29:39 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 n3GITdNJ022656 for ; Thu, 16 Apr 2009 12:29:39 -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 n3GIKCqL012617; Thu, 16 Apr 2009 13:20:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GIKCEc012616; Thu, 16 Apr 2009 13:20:12 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 13:20:12 -0500 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: KEX_OPTION (Re: applying AES-GCM to secure shell: proposed "tweak") Message-ID: <20090416182012.GA1500@Sun.COM> References: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <200904161523.LAA09381@Sparkle.Rodents-Montreal.ORG> <20090416155810.GK1500@Sun.COM> <200904161820.OAA10401@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904161820.OAA10401@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 02:13:42PM -0400, der Mouse wrote: > >>>> IF a non-AEAD cipher is chosen AND there was no common MAC AND > >>>> there was a common AEAD cipher THEN re-compute the cipher > >>>> selection ignoring all non-AEAD ciphers. > >> This rule interacts very badly with the implementation of any other > >> encryption algorithm that similarly wants to ignore MACs, especially > >> if it defines an analogous rule. > > Surely such an encryption algorithm would be an AEAD algorithm, > > therefore there is no such interaction (since the rule still > > applies). > > You truly believe that, for the entire lifetime of SSHv2, nobody will > ever come up with another way to roll tamper-evident-ness in with > encryption (or at least won't want to use such a thing with SSHv2)? > > I find that...dubious, at best. No, I'm saying that from where we stand such an algorithm would like like any other AEAD algorithm. > > Of course, Jeff's KEX_OPTION packet type needs negotiation too! > > I don't see why. Send it and let it get handled or rejected. Hmmm, I have to re-read the spec. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 11:40:00 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 E76903A6C80 for ; Thu, 16 Apr 2009 11:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.180, 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 JqEKpKWonRyR for ; Thu, 16 Apr 2009 11:40:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1502E3A6925 for ; Thu, 16 Apr 2009 11:40:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E630063B1D5; Thu, 16 Apr 2009 18:41:05 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by mail.netbsd.org (Postfix) with ESMTP id 0852763B21D for ; Thu, 16 Apr 2009 18:41:03 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GIf3Hv027297 for ; Thu, 16 Apr 2009 18:41:03 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 n3GIf3g7032658 for ; Thu, 16 Apr 2009 12:41:03 -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 n3GIGYNv012611; Thu, 16 Apr 2009 13:16:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GIGTat012610; Thu, 16 Apr 2009 13:16:29 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 16 Apr 2009 13:16:29 -0500 From: Nicolas Williams To: Damien Miller Cc: Peter Gutmann , mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090416181628.GZ1500@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Thu, Apr 16, 2009 at 08:30:18PM +1000, Damien Miller wrote: > On Thu, 16 Apr 2009, Peter Gutmann wrote: > > > >http://tools.ietf.org/html/draft-miller-secsh-compression-delayed-00 > > > > Hmm, why not just apply it only to the data packets? The random > > non-data- related messages exchanged (again, mostly high-entropy > > binary blobs) aren't going to compress much (if at all), and will only > > have the effect of messing up the compression by polluting the source > > statistics. With data-payload-only compression it'd be much cleaner > > and easier to handle, just run the compressor over the data-packet > > payload and leave everything else as is. > > Since we are expressing wishes for the transport protocol, mine is a > per-packet compression flag :) Oh! I agree, that'd be nice. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 11:50: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 B23AE3A6C57 for ; Thu, 16 Apr 2009 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.53 X-Spam-Level: X-Spam-Status: No, score=-9.53 tagged_above=-999 required=5 tests=[AWL=0.458, 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 mDIPjgpLjetY for ; Thu, 16 Apr 2009 11:50:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 5816A3A6C92 for ; Thu, 16 Apr 2009 11:50:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7459263B1F0; Thu, 16 Apr 2009 18:51:26 +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 32EA963B206 for ; Thu, 16 Apr 2009 18:51:22 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA10607; Thu, 16 Apr 2009 14:51:22 -0400 (EDT) From: der Mouse Message-Id: <200904161851.OAA10607@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: Thu, 16 Apr 2009 14:48:36 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: KEX_OPTION (Re: applying AES-GCM to secure shell: proposed "tweak") In-Reply-To: <20090416182012.GA1500@Sun.COM> References: <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <200904161523.LAA09381@Sparkle.Rodents-Montreal.ORG> <20090416155810.GK1500@Sun.COM> <200904161820.OAA10401@Sparkle.Rodents-Montreal.ORG> <20090416182012.GA1500@Sun.COM> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >>> Of course, Jeff's KEX_OPTION packet type needs negotiation too! >> I don't see why. Send it and let it get handled or rejected. > Hmmm, I have to re-read the spec. There's a spec? Perhaps we're talking about two different things. I didn't see any mention of a KEX_OPTION packet upthread, so I took this to be referring informally to an informally proposed new packet type. If there's a real proposed spec and I was just unaware of it (perhaps I missed it upthread?), then I may need to retract that, since I haven't read the 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 Thu Apr 16 13:21:05 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 A72803A6DA4 for ; Thu, 16 Apr 2009 13:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.023, 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 f7EKRUoLVwEs for ; Thu, 16 Apr 2009 13:21:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id 1D2F33A6DD6 for ; Thu, 16 Apr 2009 13:20:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3458A63B182; Thu, 16 Apr 2009 20:22:05 +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 27BD463B251 for ; Thu, 16 Apr 2009 20:22:02 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A7DA24003F; Thu, 16 Apr 2009 22:21:43 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 9B75040040; Thu, 16 Apr 2009 22:21:43 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 7DCC64003F; Thu, 16 Apr 2009 22:21:43 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3GKLx2V027944; Thu, 16 Apr 2009 22:21:59 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3GKLu0m027943; Thu, 16 Apr 2009 22:21:56 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Nicolas Williams , der Mouse , ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <20090416143030.GX1500@Sun.COM> <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 16 Apr 2009 22:21:55 +0200 In-Reply-To: <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 16 Apr 2009 10:50:10 -0400") 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 Jeffrey Hutzelman writes: > Yes, it is. The twist you describe is complicated. It's a funny > special case. What's going to happen when we have another funny > special case? We already have another one, which we may learn from: The rules for the keyexchange algorithm! (Section 7.1, RFC 4253) I have now reread these rules. Mirroring these rules for the current situation, we get the following: The following algorithm MUST be used to choose a an encryption method (independently for each direction): Iterate over client's encryption algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm is not an aead algorithm (i.e., needs separate mac), there is a mac algorithm, different from "none-if-aead", on the server's list that is also supported by the client. When processing the mac algorithm lists, consider the client's mac algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the selected encryption algorithm is not of aead type, the algorithm must be different from "none-if-aead". The final condition matters only if "none-if-aead" occurs on both the client's and the server's lists, which is why implementations that don't support aead need not know about the updated selection rules. A different, more general, way to state the same selection rules would be as follows: 1. When an algorithm on a lists of type A has a requirement on the selection of algorithms of a different type B (current examples: A = key exchange, B = host key algorithm, or A = encryption, B = mac in the same direction), check if there is some common entry on the client's and server's type B list that satisfy the requirement. If it does not, delete the entry in question from list A and continue. 2. If the type A algorithm that is selected has a requirement on the type B selection, delete all entries on the type B lists that don't satisfy the requirement. By (1), the remaining lists have at least one common element. As long as we don't introduce any circular dependencies, this should work just fine. (I haven't thought much about the case that A depends on B which depends on C, but as long as there are no cycles, I'd expect that should not cause any fundamental problems). We could ignore the problem for AEAD, but I think there's a value in consistency. The problem key exchange / host key is very similar, and then it makes a lot of sense, at least to me, to reuse the same solution. Again, it would be nice to hear from someone who has actually implemented the above logic if it works well in practice. (My implementation uses only signature algorithms and only dh keyexchange, so it's not an issue, so up to now, I haven't cared much about it). Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 16 13:56:05 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 CE8823A68DC for ; Thu, 16 Apr 2009 13:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.542 X-Spam-Level: X-Spam-Status: No, score=-9.542 tagged_above=-999 required=5 tests=[AWL=0.446, 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 57a6mZArnCfB for ; Thu, 16 Apr 2009 13:56:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:4:7:2e0:81ff:fe52:9ab6]) by core3.amsl.com (Postfix) with ESMTP id A63903A6B43 for ; Thu, 16 Apr 2009 13:55:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3E8DC63B20E; Thu, 16 Apr 2009 20:56:55 +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 7260C63B271 for ; Thu, 16 Apr 2009 20:56:53 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id QAA11790; Thu, 16 Apr 2009 16:56:52 -0400 (EDT) From: der Mouse Message-Id: <200904162056.QAA11790@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: Thu, 16 Apr 2009 16:42:29 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> <200904151014.GAA28779@Sparkle.Rodents-Montreal.ORG> <7741F7744982833960867ECA@atlantis.pc.cs.cmu.edu> <20090415210248.GG1500@Sun.COM> <20090416140435.GR1500@Sun.COM> <20090416143030.GX1500@Sun.COM> <13DB2377F03016A19FD634E6@atlantis.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list > A different, more general, way to state the same selection rules > would be as follows: [...] > [I]t would be nice to hear from someone who has actually implemented > the above logic if it works well in practice. (My implementation > uses only signature algorithms and only dh keyexchange, so it's not > an issue, so up to now, I haven't cared much about it). Well, I too have not implemented algorithms that let me test it fully (only signature-needing kex and signature-providing hostkey), but I think I've implemented kex/hk selection in full generality, and found it not _that_ big a deal. (See recv_kexinit in transport.c in the moussh source if you're curious.) /~\ 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 Apr 18 04:29:05 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 931BC3A6B60 for ; Sat, 18 Apr 2009 04:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.818 X-Spam-Level: X-Spam-Status: No, score=-4.818 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_40=-0.185, 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 puIufZ9z8Kjy for ; Sat, 18 Apr 2009 04:29:04 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id CC1E53A67DB for ; Sat, 18 Apr 2009 04:29:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3873163B1CE; Sat, 18 Apr 2009 11:30:10 +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 B3B2C63B12A for ; Sat, 18 Apr 2009 11:30:03 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DBBCB9F70F; Sat, 18 Apr 2009 23:30:02 +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 89PZTnGSZL7n; Sat, 18 Apr 2009 23:30:02 +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 50AEF9F6F0; Sat, 18 Apr 2009 23:30:02 +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 190CC1A662F8; Sat, 18 Apr 2009 23:30:01 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lv8kC-0006oI-Um; Sat, 18 Apr 2009 23:30:00 +1200 From: Peter Gutmann To: ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" In-Reply-To: <200904161541.LAA09507@Sparkle.Rodents-Montreal.ORG> Message-Id: Date: Sat, 18 Apr 2009 23:30:00 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list der Mouse writes: >If I do the "do them all and instrument" thing, I may leave the >instrumentation infrastructure in place in the shipped version and provide a >way for people to turn it on and collect the data to figure otu which form of >compression works best for their particular application. That'd be interesting data to have. (I think that if people really want to squeeze out every byte, and in particular if they're dealing with lots of small packets like the keystrokes for this email where the headers are much larger than the data, the best option is to use a protocol-aware compressor like PPP's header compression, where you can reduce most of the packet header to a single flag 'same as the last packet', except for the length field. Without thinking about it too much you could probably get the entire header into about 32 bits, including a flag for piggybacked window-adjusts to get rid of those as well. OTOH how many bytes to you really want to save in exchange for this protocol redesign?). Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 18 06:44:19 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 E8BE43A6C94 for ; Sat, 18 Apr 2009 06:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.858 X-Spam-Level: X-Spam-Status: No, score=-7.858 tagged_above=-999 required=5 tests=[AWL=-1.259, 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 Rez1FkqrseGt for ; Sat, 18 Apr 2009 06:44:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id 414223A6A3E for ; Sat, 18 Apr 2009 06:44:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B791163B202; Sat, 18 Apr 2009 13:45:28 +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 3ABDC63B1FE for ; Sat, 18 Apr 2009 13:45:24 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA00300; Sat, 18 Apr 2009 09:45:22 -0400 (EDT) From: der Mouse Message-Id: <200904181345.JAA00300@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, 18 Apr 2009 09:36:14 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Compression [was Re: applying AES-GCM to secure shell: proposed "tweak"] In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list >> If I do the "do them all and instrument" thing, I may leave the >> instrumentation infrastructure in place in the shipped version and >> provide a way for people to turn it on and collect the data to >> figure out which form of compression works best for their particular >> application. > That'd be interesting data to have. My own opinion exactly. > (I think that if people really want to squeeze out every byte, and in > particular if they're dealing with lots of small packets like the > keystrokes for this email where the headers are much larger than the > data, the best option is to use a protocol-aware compressor like > PPP's header compression, [...] Agreed. But that "target market", if you will, is not really what this was aimed at. I more had this in mind for bulk data transfer, where the question is whether the data's statistics match the headers' well enough for compressing them all together to win over compressing just the data - or, hm, compressing the headers and data with two different contexts, come to think of it. > Without thinking about it too much you could probably get the entire > header into about 32 bits, including a flag for piggybacked > window-adjusts to get rid of those as well. SSH doesn't have piggybacked window-adjusts. Or were you thinking of effectively adding them, by giving the compression code special handling for the (probably common, especially for interactive use) case of a window adjust with an immediately following small data packet? > OTOH how many bytes to you really want to save in exchange for this > protocol redesign? What protocol redesign? All this stuff can be done within existing SSHv2, as compression algorithms. /~\ 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 Apr 18 12:30:14 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 056333A68A8 for ; Sat, 18 Apr 2009 12:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[AWL=2.196, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxit+EK366LY for ; Sat, 18 Apr 2009 12:30:13 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id 55EC83A6E4B for ; Sat, 18 Apr 2009 12:30:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0477563B244; Sat, 18 Apr 2009 19:31: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 1874563B232 for ; Sat, 18 Apr 2009 19:31:18 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E0B7A40061; Sat, 18 Apr 2009 21:30:51 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id D45AD4006E; Sat, 18 Apr 2009 21:30:51 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id C00DB40064; Sat, 18 Apr 2009 21:30:51 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3IJVEZr017764; Sat, 18 Apr 2009 21:31:14 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3IJVBbC017763; Sat, 18 Apr 2009 21:31:11 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Peter Gutmann Cc: djm@mindrot.org, mouse@Rodents-Montreal.ORG, ietf-ssh@NetBSD.org Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Sat, 18 Apr 2009 21:31:11 +0200 In-Reply-To: (Peter Gutmann's message of "Thu, 16 Apr 2009 16:07:47 +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: > This is pretty much the main reason why I haven't implemented it so far. zlib > has had quite a number of security holes, and (from looking at the code in the > past) there are no doubt lots still in there - it's a huge body of incredibly > complex and not entirely comprehensible code (do you want to analyse > inflate.c/inffast.c and check that there's no potential for > overflow/underflow/overwrite/whatever in there?). Having all that exposed to > arbitrary remote attackers is too big a risk to take. Is it primarily the attack surface of inflate (uncompressing) untrusted data that worries you, or also deflate (compressing)? The reason I ask is that * Inflate should be inherently less complex to implement than deflate, * I'm awere of an alternative (but unfortunately proprietary) implementations of inflate that is claimed to be smaller and simpler than the original one in zlib. Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 18 18:49: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 0916C3A6B78 for ; Sat, 18 Apr 2009 18:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.15 X-Spam-Level: X-Spam-Status: No, score=-4.15 tagged_above=-999 required=5 tests=[AWL=2.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 BGzxT+h6LKYo for ; Sat, 18 Apr 2009 18:49:45 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id 5D2AC3A6358 for ; Sat, 18 Apr 2009 18:49:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E4ADE63B1FB; Sun, 19 Apr 2009 01:50:49 +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 E658D63B104 for ; Sun, 19 Apr 2009 01:50:46 +0000 (UTC) Received: from Atlantic ([69.57.253.76]) (authenticated user nospam@denisbider.com) by skroderider.denisbider.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 18 Apr 2009 21:48:22 -0400 Message-ID: <04FAB8A299DD4D83BAB275CB056268D3@Atlantic> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , =?ISO-8859-1?Q?Niels_=22M=F6ller=22?= Cc: , , References: In-Reply-To: Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Date: Sat, 18 Apr 2009 21:48:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I'm kinda surprised by the attitude "there's only one zlib". We use the Crypto++ implementation, which is independent of zlib, and is freely available. ----- Original Message ----- From: "Niels "Möller"" To: "Peter Gutmann" Cc: ; ; Sent: Saturday, April 18, 2009 15:31 Subject: Re: applying AES-GCM to secure shell: proposed "tweak" > Peter Gutmann writes: > >> This is pretty much the main reason why I haven't implemented it so far. >> zlib >> has had quite a number of security holes, and (from looking at the code >> in the >> past) there are no doubt lots still in there - it's a huge body of >> incredibly >> complex and not entirely comprehensible code (do you want to analyse >> inflate.c/inffast.c and check that there's no potential for >> overflow/underflow/overwrite/whatever in there?). Having all that >> exposed to >> arbitrary remote attackers is too big a risk to take. > > Is it primarily the attack surface of inflate (uncompressing) untrusted > data that worries you, or also deflate (compressing)? > > The reason I ask is that > > * Inflate should be inherently less complex to implement than deflate, > > * I'm awere of an alternative (but unfortunately proprietary) > implementations of inflate that is claimed to be smaller and simpler > than the original one in zlib. > > Regards, > /Niels > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 18 22:40:05 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 70C703A6C60 for ; Sat, 18 Apr 2009 22:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.597, 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 6HWdUQdtpyyi for ; Sat, 18 Apr 2009 22:40:04 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id AD68D3A68D2 for ; Sat, 18 Apr 2009 22:40:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9709763B180; Sun, 19 Apr 2009 05:41:12 +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 07ACE63B14A for ; Sun, 19 Apr 2009 05:41:06 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 492FB171B0E; Sun, 19 Apr 2009 17:41:05 +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 XjlBhI4es1FG; Sun, 19 Apr 2009 17:41:05 +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 F2830171B0C; Sun, 19 Apr 2009 17:41:04 +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 D5C941DE4001; Sun, 19 Apr 2009 17:41:03 +1200 (NZST) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LvPm3-0005uq-NG; Sun, 19 Apr 2009 17:41:03 +1200 From: Peter Gutmann To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Cc: djm@mindrot.org, ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG In-Reply-To: Message-Id: Date: Sun, 19 Apr 2009 17:41:03 +1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: >Is it primarily the attack surface of inflate (uncompressing) untrusted data >that worries you, or also deflate (compressing)? Purely inflate. I'd be kinda surprised if you could cause problems with input data, at best you can cause O( n^2 ) behaviour until the hash chain truncation takes effect. >* Inflate should be inherently less complex to implement than deflate, Have a look at the source code :-). >* I'm awere of an alternative (but unfortunately proprietary) implementations >of inflate that is claimed to be smaller and simpler than the original one in >zlib. Also less audited/less exposed to attack and scrutiny. Insert standard open- vs. closed-source argument here. The real issue though isn't to try and figure out which one is less risky, but a basic "don't do that, then". Peter. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 19 13:49: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 C744A3A6819 for ; Sun, 19 Apr 2009 13:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=0.454, 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 gSHHdyFgMQ5r for ; Sun, 19 Apr 2009 13:49:33 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id EBB8C3A65A6 for ; Sun, 19 Apr 2009 13:49:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1889063B1D5; Sun, 19 Apr 2009 20:50:41 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id 9CF6563B257 for ; Sun, 19 Apr 2009 20:50:14 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3JKo9Ap024452 for ; Sun, 19 Apr 2009 20:50:10 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 n3JKo93L060450 for ; Sun, 19 Apr 2009 14:50: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 n3JKI5th014018; Sun, 19 Apr 2009 15:18:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3JKI3HN014017; Sun, 19 Apr 2009 15:18:03 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 19 Apr 2009 15:18:03 -0500 From: Nicolas Williams To: Peter Gutmann Cc: nisse@lysator.liu.se, djm@mindrot.org, ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090419201802.GZ1500@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list On Sun, Apr 19, 2009 at 05:41:03PM +1200, Peter Gutmann wrote: > nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) writes: > >Is it primarily the attack surface of inflate (uncompressing) untrusted data > >that worries you, or also deflate (compressing)? > > Purely inflate. I'd be kinda surprised if you could cause problems with input > data, at best you can cause O( n^2 ) behaviour until the hash chain truncation > takes effect. > > >* Inflate should be inherently less complex to implement than deflate, > > Have a look at the source code :-). > > >* I'm awere of an alternative (but unfortunately proprietary) implementations > >of inflate that is claimed to be smaller and simpler than the original one in > >zlib. > > Also less audited/less exposed to attack and scrutiny. Insert standard open- > vs. closed-source argument here. The real issue though isn't to try and > figure out which one is less risky, but a basic "don't do that, then". +1. Don't compress/uncompress in privileged code. By and large it's easy to separate privilege post-authentication (since privilege will be needed only for things like logout processing). So postponing compression till after authentication would be a good thing. Besides, there's nothing much worth compressing between version banner exchange, key exchange and authentication (well, if we keep adding algs then KEXINIT may become significantly compressible :) Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 20 00:44:32 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 6E8833A6884 for ; Mon, 20 Apr 2009 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruAOxC-6gFQZ for ; Mon, 20 Apr 2009 00:44:31 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by core3.amsl.com (Postfix) with ESMTP id B34F43A6CE9 for ; Mon, 20 Apr 2009 00:44:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DA4A363B284; Mon, 20 Apr 2009 07:45: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 802C663B27A for ; Mon, 20 Apr 2009 07:45:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 89CFF4006D; Mon, 20 Apr 2009 09:45:11 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 7D2D740082; Mon, 20 Apr 2009 09:45:11 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 611054006D; Mon, 20 Apr 2009 09:45:11 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3K7jYrn005989; Mon, 20 Apr 2009 09:45:34 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3K7jP31005986; Mon, 20 Apr 2009 09:45:25 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Peter Gutmann Cc: djm@mindrot.org, ietf-ssh@NetBSD.org, mouse@Rodents-Montreal.ORG Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Mon, 20 Apr 2009 09:45:24 +0200 In-Reply-To: (Peter Gutmann's message of "Sun, 19 Apr 2009 17:41:03 +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: > Have a look at the source code :-). Summing line counts of inflate, inflate_fast and inflate_table, I get some 1134 lines, of quite complex code. > Also less audited/less exposed to attack and scrutiny. Insert standard open- > vs. closed-source argument here. The real issue though isn't to try and > figure out which one is less risky, but a basic "don't do that, then". I'm of course not seriously considering using a proprietary zlib implementation. My thinking was rather that maybe, inflate can be implemented with much less complexity? Either in general, or for the context that matters for ssh and similar protocols (we can pass a full ssh message to the decompressor, and we can pass an output buffer matching the maximum message size. Then most of the state-machinery in the zlib implementation is unnecessary). Regards, /Niels From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 21 10:06:12 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 80E983A6B68 for ; Tue, 21 Apr 2009 10:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.172, 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 8ra-uXI4ga4J for ; Tue, 21 Apr 2009 10:06: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 3B5183A68CD for ; Tue, 21 Apr 2009 10:06:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C41F763B13D; Tue, 21 Apr 2009 17:07:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mail.netbsd.org (Postfix) with ESMTPS id B417263B151 for ; Tue, 21 Apr 2009 17:07:15 +0000 (UTC) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3LH7EUW026850 for ; Tue, 21 Apr 2009 17:07:15 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 n3LH7EJ9024531 for ; Tue, 21 Apr 2009 11:07:14 -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 n3LGgjAM015216; Tue, 21 Apr 2009 11:42:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LGggEx015215; Tue, 21 Apr 2009 11:42:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 21 Apr 2009 11:42:42 -0500 From: Nicolas Williams To: Tim Polk Cc: ietf-ssh@NetBSD.org, Tero Kivinen , Bill Sommerfeld , Chris Lonvick , ylo@ssh.com, "Igoe, Kevin M." , "Jerome A. Solinas" , " Eronen" Subject: Re: applying AES-GCM to secure shell: proposed "tweak" Message-ID: <20090421164242.GO1500@Sun.COM> References: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9311F3B1-7185-4A1B-A833-B8DEE63B90B8@nist.gov> User-Agent: Mutt/1.5.7i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list I've confirmed with an expert who should know (Darren Moffat) that the PKCS#11 AEAD interfaces DO NOT allow retrieval of any plaintext before the authentication tag has been found and verified. It makes sense even for AEAD modes which can be seen composed generically with a MAC (and especially for those that can't be). Suppose we do something like C_DecryptInit(), C_DecryptUpdate(), ..., C_DecryptFinal(), and the first bit of input is just long enough to contain an authentication tag, then the mechanism can't know whether it is ciphertext or a tag until more of the message is provided via C_DecryptUpdate(). Nico -- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 26 17:24:50 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 543AC3A68DB for ; Sun, 26 Apr 2009 17:24:50 -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 lyLZ+ZqsjGHs for ; Sun, 26 Apr 2009 17:24: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 525F33A6844 for ; Sun, 26 Apr 2009 17:24:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C84E263B1E1; Mon, 27 Apr 2009 00:26:04 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from services107.math.uwaterloo.ca (services107.math.uwaterloo.ca [129.97.140.58]) by mail.netbsd.org (Postfix) with ESMTP id 758A663B1C2 for ; Mon, 27 Apr 2009 00:26:01 +0000 (UTC) Received: from [131.181.103.100] ([131.181.103.100]) (authenticated bits=0) by services107.math.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id n3R0PsP6001452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 26 Apr 2009 20:25:59 -0400 (EDT) Message-Id: <12E084D9-630E-4F9C-B48B-63FF27DE2E4A@stebila.ca> From: Douglas Stebila To: ietf-ssh@netbsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Fwd: New Version Notification for draft-green-secsh-ecc-07 Date: Mon, 27 Apr 2009 10:25:50 +1000 References: <20090427001853.AEBF23A68DB@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (services107.math.uwaterloo.ca [129.97.140.58]); Sun, 26 Apr 2009 20:26:00 -0400 (EDT) X-Miltered: at mailchk-w03 with ID 49F4FB92.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: clamav-milter 0.95.1 at mailchk-w01 X-Virus-Status: Clean X-UUID: dc1a672d-2c39-44c7-bd68-c7dd75c099a4 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh Precedence: list As a result of the discussion earlier this month regarding the ECC in SSH draft, I have updated the draft accordingly. The main change is how method names are chosen. For the three required curves, the method names contain a text representation of the curve name: ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 For the remaining optional curves, including all remaining recommended NIST and SEC curves, the method names contain the ASCII representation of the OID, for example, ecdh-sha2-1.3.132.0.33 Although the 64 character length restriction on method names means that, theoretically, not all OIDs can be represented in this way, I am convinced by the arguments that there are unlikely to be such long OIDs in practice and that the benefit of having human (and Google) readable method names outweighs the drawbacks of not being able to include arbitrarily-long OIDs. The draft is available at http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-07.txt Douglas Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 27, 2009 10:18:53 AM GMT+10:00 > To: douglas@stebila.ca > Cc: jon.green@ece.queensu.ca > Subject: New Version Notification for draft-green-secsh-ecc-07 > > > A new version of I-D, draft-green-secsh-ecc-07.txt has been > successfuly submitted by Douglas Stebila and posted to the IETF > repository. > > Filename: draft-green-secsh-ecc > Revision: 07 > Title: Elliptic-Curve Algorithm Integration in the Secure Shell > Transport Layer > Creation_date: 2009-04-27 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > This document describes algorithms based on Elliptic Curve > Cryptography (ECC) for use within the Secure Shell (SSH) transport > protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman > (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key > agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for > use in the SSH Transport Layer protocol. > > > > The IETF Secretariat. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 30 04:40: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 C21583A6A44 for ; Thu, 30 Apr 2009 04:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_05=-1.11, HELO_EQ_SE=0.35, J_CHICKENPOX_32=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 9tkt-rqryHYi for ; Thu, 30 Apr 2009 04:40: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 440B73A6B8B for ; Thu, 30 Apr 2009 04:40:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B382E63B123; Thu, 30 Apr 2009 11:41: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 A721D63B143 for ; Thu, 30 Apr 2009 11:41:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 5A96A4007D; Thu, 30 Apr 2009 13:41:11 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1674) id 4E47C4007C; Thu, 30 Apr 2009 13:41:11 +0200 (CEST) Received: from koeberg.lysator.liu.se (koeberg.lysator.liu.se [130.236.254.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 12BA04007D; Thu, 30 Apr 2009 13:41:11 +0200 (CEST) Received: from koeberg.lysator.liu.se (localhost [127.0.0.1]) by koeberg.lysator.liu.se (8.13.8+Sun/8.13.4) with ESMTP id n3UBfYfp009543; Thu, 30 Apr 2009 13:41:34 +0200 (MEST) Received: (from nisse@localhost) by koeberg.lysator.liu.se (8.13.8+Sun/8.12.8/Submit) id n3UBfVFu009542; Thu, 30 Apr 2009 13:41:31 +0200 (MEST) X-Authentication-Warning: koeberg.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider \(Bitvise\)" Cc: "Peter Gutmann" , , , Subject: Re: applying AES-GCM to secure shell: proposed "tweak" References: <04FAB8A299DD4D83BAB275CB056268D3@Atlantic> From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Date: Thu, 30 Apr 2009 13:41:30 +0200 In-Reply-To: <04FAB8A299DD4D83BAB275CB056268D3@Atlantic> (denis bider's message of "Sat, 18 Apr 2009 21:48:36 -0400") 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 "denis bider \(Bitvise\)" writes: > I'm kinda surprised by the attitude "there's only one zlib". > > We use the Crypto++ implementation, which is independent of zlib, and > is freely available. In order to figure out what complexity really is needed, I had to write my own implementation. I'm not going to claim that it's less buggy than zlib (it's the result of a few evenings work and not thouroghly tested), but it's certainly a lot smaller than zlib and (imo) well designed and fairly readable. See http://www.lysator.liu.se/~nisse/archive/inflate-0.2.tar.gz. For now, it's GPL:ed. The interesting files, huffman.c and inflate.c, are in total 674 lines, or 490 excluding the comments (2015 and 1467 for the corresponding files in zlib, inflate.c, inffast.c and inftrees.c). Performance is a factor two slower than the ordinary zcat program. Best regards, /Niels