From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 04:05:36 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B991A012B for ; Fri, 4 Apr 2014 04:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9FE8DD4Q6Cx for ; Fri, 4 Apr 2014 04:05:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD111A0133 for ; Fri, 4 Apr 2014 04:05:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2242F14A325; Fri, 4 Apr 2014 11:05:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DB28B14A322 for ; Fri, 4 Apr 2014 11:05:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id l7uMja_OADR9 for ; Fri, 4 Apr 2014 11:05:21 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 900BC14A31A for ; Fri, 4 Apr 2014 11:05:19 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WW0tb-0001T1-7i; Fri, 04 Apr 2014 10:58:47 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org Subject: Protocol ambiguity: want_reply vs CHANNEL_CLOSE MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 04 Apr 2014 10:58:47 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I think this list still reaches a reasonable number of SSH implementors. I'd like to see if we can get a consensus on the following problem. Suppose two SSH implementations have a channel open between them. Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the want_reply flag set. Party B, meanwhile, independently decides to initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE. These two messages cross in the network, so that B receives the channel request after it's already sent a close message for that channel. Should B send a reply? I think you can argue it either way from the spec. RFC 4254 section 5.4 says that channel requests must be replied to if they have want_reply set, and doesn't make any exception for channels in the middle of closing, which supports the answer 'yes'. Then again, section 5.3 says that after a party has both sent and received CLOSE, the channel is defunct and its number can be reused, which supports the answer 'no' (because, if B does reply, what if that reply crosses with A's responding close message? Then B's reply would arrive at A after A has both sent and received CLOSE). So I think this is a genuine ambiguity in the RFC. Moreover, I've observed SSH servers disagreeing on whether to reply, which makes it fiddly to implement a policy at the request-sending end that handles both kinds of server. Would anyone like to state an opinion on what ought to happen about this? I can think of two reasonably sensible options: (a) Issue a clarifying RFC that resolves the ambiguity by designating one or other behaviour as correct, and consider implementations doing the other thing to have a bug requiring a fix. (b) Issue an RFC specifying a protocol extension that allows an implementation to advertise which interpretation it will follow (since either behaviour is easy to cope with if you know which one you're talking to). I suppose we'd still have to decide on the default answer in the absence of such an advertisement. Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the terminally confused is only apparent to the latter." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 07:40:59 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3C1A01AA for ; Fri, 4 Apr 2014 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YfjnI5W9JsO for ; Fri, 4 Apr 2014 07:40:55 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3682E1A0191 for ; Fri, 4 Apr 2014 07:40:55 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B735114A3D7; Fri, 4 Apr 2014 14:40:41 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0333214A3CD for ; Fri, 4 Apr 2014 14:40:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id YWgm7H5ssINt for ; Fri, 4 Apr 2014 14:40:37 +0000 (UTC) Received: from mail-ext-out1.uwa.edu.au (mail-ext-out1.uwa.edu.au [130.95.3.210]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 75AA814A3D6 for ; Fri, 4 Apr 2014 14:40:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEauPlOCX4DP/2dsb2JhbABXyCWBNnSCJQEBAQQ6PxALDgoJJQ8FGDGIDM9YF45xB4Q4BIlYjwKKYYdfgz0 X-IPAS-Result: Ap4EAEauPlOCX4DP/2dsb2JhbABXyCWBNnSCJQEBAQQ6PxALDgoJJQ8FGDGIDM9YF45xB4Q4BIlYjwKKYYdfgz0 X-IronPort-AV: E=Sophos;i="4.97,795,1389715200"; d="scan'208";a="59473971" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 04 Apr 2014 21:09:46 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 280A93C07B; Fri, 4 Apr 2014 21:09:46 +0800 (WST) Received: from motsugo.ucc.gu.uwa.edu.au (motsugo.ucc.gu.uwa.edu.au [130.95.13.7]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id EC1613C07B; Fri, 4 Apr 2014 21:09:45 +0800 (WST) Received: by motsugo.ucc.gu.uwa.edu.au (Postfix, from userid 11154) id E4A9320073; Fri, 4 Apr 2014 21:09:45 +0800 (WST) Date: Fri, 4 Apr 2014 21:09:45 +0800 From: Matt Johnston To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE Message-ID: <20140404130945.GZ20121@ucc.gu.uwa.edu.au> Mail-Followup-To: Simon Tatham , ietf-ssh@netbsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-snowman: =?utf-8?B?4piD?= User-Agent: Mutt/1.5.21 (2010-09-15) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, Apr 04, 2014 at 10:58:47AM +0100, Simon Tatham wrote: > Suppose two SSH implementations have a channel open between them. > Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the > want_reply flag set. Party B, meanwhile, independently decides to > initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE. > These two messages cross in the network, so that B receives the > channel request after it's already sent a close message for that > channel. > > Should B send a reply? I'd say no. It's hard to imagine a situation where the reply would not be SSH_MSG_REQUEST_FAILURE, and a requestor wouldn't be able to do much with a "success" reply in any case. In addition it adds an another state for implementations to handle, "both sides closed but waiting for a reply". Given there are millions of deployed servers that won't change, would it be best to just publish a RFC and keep using a compatibility table? Out of interest has PuTTY encountered this problem in the wild? FWIW Dropbear ignores requests after having sent SSH_MSG_CHANNEL_CLOSE, though that was more from omission of the wantreply case. All SSH_MSG_CHANNEL_REQUEST messages have wantreply=0, so no replies are expected. Cheers, Matt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 08:01:26 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15861A0191 for ; Fri, 4 Apr 2014 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDoInLNjwAyv for ; Fri, 4 Apr 2014 08:01:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4A41A0134 for ; Fri, 4 Apr 2014 08:01:22 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7AD5214A3EE; Fri, 4 Apr 2014 15:01:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4F08814A3E6 for ; Fri, 4 Apr 2014 15:01:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id U1bIYfNqvBKH for ; Fri, 4 Apr 2014 15:01:12 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2407F14A3E3 for ; Fri, 4 Apr 2014 15:01:11 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WW5c3-0002LS-3R; Fri, 04 Apr 2014 16:00:59 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <20140404130945.GZ20121@ucc.gu.uwa.edu.au> To: Matt Johnston Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 04 Apr 2014 16:00:59 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Matt Johnston wrote: > Given there are millions of deployed servers that won't change, would > it be best to just publish a RFC and keep using a compatibility table? In other words, designate one answer as 'right' and recommended for new servers, but also keep a list of implementations known to do the other thing? I suppose that's not too onerous; it's a bit out of the ordinary as bug workarounds go, but then a fundamental protocol issue that's been around forever _is_ a bit out of the ordinary. > Out of interest has PuTTY encountered this problem in the wild? Yes. We use a channel request with want_reply set as a means of measuring round-trip time so as to tune our window size, which means that if a server closes a channel at all it's quite common for us to have just sent a channel request at the point it does so. And yes, we have encountered at least one server with each policy! Cheers, Simon -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 08:29:55 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2811A01EE for ; Fri, 4 Apr 2014 08:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sacoIyE8_0Ef for ; Fri, 4 Apr 2014 08:29:50 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 820761A01D7 for ; Fri, 4 Apr 2014 08:29:50 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A98BD14A404; Fri, 4 Apr 2014 15:29:45 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 913D614A3F6 for ; Fri, 4 Apr 2014 15:29:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id zqCrtMvy0zSG for ; Fri, 4 Apr 2014 15:29:43 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9A50414A2BE for ; Fri, 4 Apr 2014 15:29:42 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WW63f-0004XB-BA; Fri, 04 Apr 2014 16:29:31 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: "denis bider \(Bitvise\)" Cc: "Matt Johnston" , Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 04 Apr 2014 16:29:31 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list "denis bider \(Bitvise\)" wrote: > The behavior that accommodates all request responders is as follows: [...] > - Do not reuse channel numbers, so that you can reliably ignore channel > request responses received after CLOSE. The trouble with that is that it's _horrible_! The intention of the SSH protocol design was always that channel numbers should be reusable, so that SSH sessions do not have a designed-in lifetime limit. 2^32 channel opens and closes is certainly a lot, but it isn't beyond the bounds of belief in situations of (for example) heavy WWW use over SOCKS forwarding in a long-lived connection. It may be necessary to use this as a kludgy workaround for some particular server, if we really cannot determine from its version string which policy it follows, but I cannot bring myself to believe it's the sensible policy to apply in all situations. Cheers, Simon -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 09:12:20 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EFE1A0238 for ; Fri, 4 Apr 2014 09:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV_zC7jF3d9J for ; Fri, 4 Apr 2014 09:12:09 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 458591A021E for ; Fri, 4 Apr 2014 09:12:09 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1987D14A40C; Fri, 4 Apr 2014 16:12:02 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 75EE214A40B for ; Fri, 4 Apr 2014 16:11:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id fJgrPBSKYS_e for ; Fri, 4 Apr 2014 16:11:55 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C60A514A3FA for ; Fri, 4 Apr 2014 16:11:55 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher AES128-SHA256 (128 bits)); Fri, 4 Apr 2014 16:11:15 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Matt Johnston" , "Simon Tatham" Cc: References: <20140404130945.GZ20121@ucc.gu.uwa.edu.au> In-Reply-To: <20140404130945.GZ20121@ucc.gu.uwa.edu.au> Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE Date: Fri, 4 Apr 2014 09:11:15 -0600 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Out of interest has PuTTY encountered this problem in the wild? Yes, with our server (Bitvise). The way I see this issue is that in the described situation, the request sender can implement behavior that accommodates all responders, but the request responder cannot implement behavior that accommodates all request senders. The behavior that accommodates all request responders is as follows: - Do not wait for channel request responses after receiving CLOSE. - Do not reuse channel numbers, so that you can reliably ignore channel request responses received after CLOSE. On the responder's end, however, there are these choices: - If a channel request arrives after we sent CLOSE, but before we received remote CLOSE, ignore it. This will work for request senders which don't wait for request responses after CLOSE, but it will hurt request senders that do. - Alternately, if a channel request arrives after we sent CLOSE, but before we received remote CLOSE, reply to it. This will work for request senders which wait for request responses after CLOSE, but it creates a possible race condition for request senders which do not: (a) The request sender might have already sent CLOSE that we haven't received yet, might have freed channel state, and might abort the session due to unexpected channel number in request response. (b) Alternately, the request sender might have already sent CLOSE that we haven't received yet, and immediately after, respond to our CHANNEL_OPEN that we might have just sent. The request sender might then interpret our response as arriving on that new channel, rather than the previous one being closed. With millions of SSH implementations out there, we are no longer in a position to mandate behavior that makes implementations incompatible with one another. I think we ought to advise in favor of the most compatible strategy, which is: - Do not reuse channel numbers. - Do not send responses after sending CLOSE. - Do not wait for responses after receiving CLOSE. denis -----Original Message----- From: Matt Johnston Sent: Friday, April 4, 2014 07:09 To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE On Fri, Apr 04, 2014 at 10:58:47AM +0100, Simon Tatham wrote: > Suppose two SSH implementations have a channel open between them. > Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the > want_reply flag set. Party B, meanwhile, independently decides to > initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE. > These two messages cross in the network, so that B receives the > channel request after it's already sent a close message for that > channel. > > Should B send a reply? I'd say no. It's hard to imagine a situation where the reply would not be SSH_MSG_REQUEST_FAILURE, and a requestor wouldn't be able to do much with a "success" reply in any case. In addition it adds an another state for implementations to handle, "both sides closed but waiting for a reply". Given there are millions of deployed servers that won't change, would it be best to just publish a RFC and keep using a compatibility table? Out of interest has PuTTY encountered this problem in the wild? FWIW Dropbear ignores requests after having sent SSH_MSG_CHANNEL_CLOSE, though that was more from omission of the wantreply case. All SSH_MSG_CHANNEL_REQUEST messages have wantreply=0, so no replies are expected. Cheers, Matt From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 4 09:13:52 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1221A01F8 for ; Fri, 4 Apr 2014 09:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoBe0ITMc53n for ; Fri, 4 Apr 2014 09:13:41 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 51E121A01F3 for ; Fri, 4 Apr 2014 09:13:41 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A3BEC14A416; Fri, 4 Apr 2014 16:13:36 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 041E914A410 for ; Fri, 4 Apr 2014 16:13:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id GkoERPl2OWMj for ; Fri, 4 Apr 2014 16:13:32 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 75A9714A40F for ; Fri, 4 Apr 2014 16:13:32 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher AES128-SHA256 (128 bits)); Fri, 4 Apr 2014 16:38:09 +0100 Message-ID: <0B0F1291617E4C0ABD2D1290C95AA390@Tenochtitlan> From: "denis bider \(Bitvise\)" To: "Simon Tatham" Cc: "Matt Johnston" , References: In-Reply-To: Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE Date: Fri, 4 Apr 2014 09:38:30 -0600 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list You don't have to avoid reusing ALL channel numbers, just recent ones. What our implementation does is: - Increment channel number up to 2^32, then wrap around. - If the channel number we're trying to use is already in use, try next one. You could also conceivably do something else, like: - Reuse channel numbers, but - Not channel numbers that were used within the last X minutes of operation. denis -----Original Message----- From: Simon Tatham Sent: Friday, April 4, 2014 09:29 To: denis bider (Bitvise) Cc: Matt Johnston ; ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE "denis bider \(Bitvise\)" wrote: > The behavior that accommodates all request responders is as follows: [...] > - Do not reuse channel numbers, so that you can reliably ignore channel > request responses received after CLOSE. The trouble with that is that it's _horrible_! The intention of the SSH protocol design was always that channel numbers should be reusable, so that SSH sessions do not have a designed-in lifetime limit. 2^32 channel opens and closes is certainly a lot, but it isn't beyond the bounds of belief in situations of (for example) heavy WWW use over SOCKS forwarding in a long-lived connection. It may be necessary to use this as a kludgy workaround for some particular server, if we really cannot determine from its version string which policy it follows, but I cannot bring myself to believe it's the sensible policy to apply in all situations. Cheers, Simon -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 6 05:45:50 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256EF1A03FC for ; Sun, 6 Apr 2014 05:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq4tIy3iyWlU for ; Sun, 6 Apr 2014 05:45:45 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id D94521A03F8 for ; Sun, 6 Apr 2014 05:45:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 60C5A14A24E; Sun, 6 Apr 2014 12:45:38 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4DF4D14A245 for ; Sun, 6 Apr 2014 12:45:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id IXrp39bfs0qZ for ; Sun, 6 Apr 2014 12:45:33 +0000 (UTC) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1CAE714A1A8 for ; Sun, 6 Apr 2014 12:45:32 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s36CjTwo021394; Sun, 6 Apr 2014 14:45:29 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s36CjRZ1021393; Sun, 6 Apr 2014 14:45:27 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE References: Date: Sun, 06 Apr 2014 14:45:27 +0200 In-Reply-To: (Simon Tatham's message of "Fri, 04 Apr 2014 10:58:47 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > Suppose two SSH implementations have a channel open between them. > Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the > want_reply flag set. Party B, meanwhile, independently decides to > initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE. > These two messages cross in the network, so that B receives the > channel request after it's already sent a close message for that > channel. > > Should B send a reply? I'd say no. I think it is pretty clear that the intention is that the CLOSE message is the final one. So that the receiver of the CLOSE close message can respond with a CLOSE, unless it has already sent one, and then forget *all* state of the channel. (Maybe one also have the option to sending additional messages before responding with a matching CLOSE. I don't know if any implementations do that. I think receiving a CLOSE means that the other end has lost all interest in the channel, and then it doesn't make any sense to send anything but a matching CLOSE). > Would anyone like to state an opinion on what ought to happen about > this? I can think of two reasonably sensible options: > > (a) Issue a clarifying RFC that resolves the ambiguity by designating > one or other behaviour as correct, and consider implementations > doing the other thing to have a bug requiring a fix. I think it would be useful to sort out what problems that bug causes, and if there are any reasonable workarounds. I think there are a couple of cases: 1. We receive an unexpected response (which the sender intended for a now dead channel). Treated an a protocol error, and handled by closing the connection. Here's one has the option of ignoring unexpected responses, possibly depending on the other side's version string. 2. We send a CHANNEL_REQUEST for a channel and get two replies (where the first was intended for a no longer alive channel). I imagine this could lead to more subtle problems. This is the case that can be eliminated by following the suggestion of not reusing channel numbers. 3. The implementation at the other end somehow expects a response after CLOSE, and not sending that breaks it's channel close handshake logic, leaving a channel alive for ever. I hope this problem doesn't require any new workarounds: The other end is typically untrusted, and we shouldn't let deviations like this cause us any big problems. Can you give us some more details on the problems you have encountered? Maybe there are simple workarounds for 95% of the problems, maybe there isn't. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 7 06:45:53 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081F1A0426 for ; Mon, 7 Apr 2014 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCuWotH0fjEa for ; Mon, 7 Apr 2014 06:45:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 4499E1A072F for ; Mon, 7 Apr 2014 06:45:47 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7035014A211; Mon, 7 Apr 2014 13:45:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 42B8014A20D for ; Mon, 7 Apr 2014 13:45:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id Hq_DN7dc3p7E for ; Mon, 7 Apr 2014 13:45:34 +0000 (UTC) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5460C14A1D2 for ; Mon, 7 Apr 2014 13:45:33 +0000 (UTC) Received: from simon by atreus.tartarus.org with local (Exim 4.69) (envelope-from ) id 1WX9rd-0004G1-JP; Mon, 07 Apr 2014 14:45:30 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 07 Apr 2014 14:45:29 +0100 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) wrote: > Can you give us some more details on the problems you have encountered? Background: as I mentioned in a previous message, PuTTY periodically sends a bogus channel request "winadj@putty.projects.tartarus.org", with want_reply set. There is no correct handling defined for this request, so we expect CHANNEL_FAILURE from the server (though we know of at least one server which amusingly sends CHANNEL_SUCCESS :-). We use the timing of that failure message to gauge the round-trip time and tune our window size. All problems I've seen with this race condition have related to these winadj messages. (So the usual workaround if a server is not playing nicely with PuTTY is to suppress winadjes.) The first problem we noticed was precisely your #1: PuTTY would crash out with 'Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 256' type messages, which turned out to be because the server was sending us CHANNEL_FAILURE after CHANNEL_CLOSE whereas we were expecting that CHANNEL_CLOSE meant the server would send no further messages about that channel. We observed this with several servers: my email archives mention Dropbear 0.51 in 2008, OpenSSH 5.1p1 in 2010, and at least one or two SSH servers in embedded devices for which I didn't get full details. Dropbear promptly fixed the problem (changing the server to stop sending post-close CHANNEL_FAILURE). OpenSSH did not, because Damien Miller questioned my analysis of it as a server-side bug on the basis that the spec was unclear (which indeed it is): https://bugzilla.mindrot.org/show_bug.cgi?id=1818 Since OpenSSH didn't make any changes, and since I'd forgotten the previous Dropbear incident at that time, I implemented PuTTY's current workaround, which is to defer _sending_ CHANNEL_CLOSE until it's seen all outstanding CHANNEL_FAILURE messages, so that (from our POV) the channel is still not completely closed at the point when those failures arrive. Unfortunately, it apparently didn't occur to me that that would break interoperation with servers that _don't_ send the outstanding failure messages, because now PuTTY sits and waits for a failure message that will never arrive and so users see hangs on the client side. So, clearly some kind of workaround is needed. But separately from the question of stopgap workarounds while we all sort ourselves out, I'd like to establish a consensus on what the right behaviour _is_, so that SSH implementations can gradually converge on that, and so that in any further situation where a client and a server don't work well together, there's a document to point to which will make it clear which one is wrong, so that we don't have 'no, _you_ fix it' deadlocks between equally stubborn implementors. Responses so far have all said that the consensus is to rule that sending FAILURE after CLOSE is wrong, and that agrees with my original belief (before I started finding out that not everyone agreed). The only people I know who have so far _deliberately_ gone with the other behaviour (in the sense of arguing against fixing it when it was pointed out) are the OpenSSH maintainers. Are any of them reading this? Cheers, Simon -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 7 07:51:04 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A451A0785 for ; Mon, 7 Apr 2014 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNLKREsS-mI8 for ; Mon, 7 Apr 2014 07:50:52 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB851A0468 for ; Mon, 7 Apr 2014 07:50:52 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A1B3414A224; Mon, 7 Apr 2014 14:50:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 209CE14A20B for ; Mon, 7 Apr 2014 14:50:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 143otDTKUY5v for ; Mon, 7 Apr 2014 14:50:36 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 56BA814A20A for ; Mon, 7 Apr 2014 14:50:36 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher AES128-SHA256 (128 bits)); Mon, 7 Apr 2014 15:50:30 +0100 Message-ID: <0A8C433AF1514C5C9CDFD499190556C8@Tenochtitlan> From: "denis bider \(Bitvise\)" To: "Simon Tatham" , =?iso-8859-1?Q?Niels_=22M=F6ller=22?= Cc: References: In-Reply-To: Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE Date: Mon, 7 Apr 2014 08:51:03 -0600 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I really still think this is a simple issue for the request sender to solve. After CLOSE is received, instead of keeping the channel alive indefinitely, keep it in a zombie state for up to X minutes. Don't make a channel in this zombie state keep a session open, if it would otherwise be closed. If you receive any outstanding responses during zombie state, this lets you recognize them and ignore them and not mix them up with any other channels that might have been opened in the meanwhile. You don't need to know what OpenSSH implementors think because this strategy works regardless of their opinion. You don't need a spec or a community consensus to back this strategy because you don't have to defend this strategy against anyone; it works with all request responders. It simply makes sense to implement. -----Original Message----- From: Simon Tatham Sent: Monday, April 7, 2014 07:45 To: Niels "Möller" Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) wrote: > Can you give us some more details on the problems you have encountered? Background: as I mentioned in a previous message, PuTTY periodically sends a bogus channel request "winadj@putty.projects.tartarus.org", with want_reply set. There is no correct handling defined for this request, so we expect CHANNEL_FAILURE from the server (though we know of at least one server which amusingly sends CHANNEL_SUCCESS :-). We use the timing of that failure message to gauge the round-trip time and tune our window size. All problems I've seen with this race condition have related to these winadj messages. (So the usual workaround if a server is not playing nicely with PuTTY is to suppress winadjes.) The first problem we noticed was precisely your #1: PuTTY would crash out with 'Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 256' type messages, which turned out to be because the server was sending us CHANNEL_FAILURE after CHANNEL_CLOSE whereas we were expecting that CHANNEL_CLOSE meant the server would send no further messages about that channel. We observed this with several servers: my email archives mention Dropbear 0.51 in 2008, OpenSSH 5.1p1 in 2010, and at least one or two SSH servers in embedded devices for which I didn't get full details. Dropbear promptly fixed the problem (changing the server to stop sending post-close CHANNEL_FAILURE). OpenSSH did not, because Damien Miller questioned my analysis of it as a server-side bug on the basis that the spec was unclear (which indeed it is): https://bugzilla.mindrot.org/show_bug.cgi?id=1818 Since OpenSSH didn't make any changes, and since I'd forgotten the previous Dropbear incident at that time, I implemented PuTTY's current workaround, which is to defer _sending_ CHANNEL_CLOSE until it's seen all outstanding CHANNEL_FAILURE messages, so that (from our POV) the channel is still not completely closed at the point when those failures arrive. Unfortunately, it apparently didn't occur to me that that would break interoperation with servers that _don't_ send the outstanding failure messages, because now PuTTY sits and waits for a failure message that will never arrive and so users see hangs on the client side. So, clearly some kind of workaround is needed. But separately from the question of stopgap workarounds while we all sort ourselves out, I'd like to establish a consensus on what the right behaviour _is_, so that SSH implementations can gradually converge on that, and so that in any further situation where a client and a server don't work well together, there's a document to point to which will make it clear which one is wrong, so that we don't have 'no, _you_ fix it' deadlocks between equally stubborn implementors. Responses so far have all said that the consensus is to rule that sending FAILURE after CLOSE is wrong, and that agrees with my original belief (before I started finding out that not everyone agreed). The only people I know who have so far _deliberately_ gone with the other behaviour (in the sense of arguing against fixing it when it was pointed out) are the OpenSSH maintainers. Are any of them reading this? Cheers, Simon -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 7 07:58:13 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4977D1A0447 for ; Mon, 7 Apr 2014 07:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqn0YLCsaqsQ for ; Mon, 7 Apr 2014 07:58:02 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id EFB401A01BE for ; Mon, 7 Apr 2014 07:57:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2F3F614A20F; Mon, 7 Apr 2014 14:57:52 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A65EB14A1AF for ; Mon, 7 Apr 2014 14:57:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id WboV2lJT1uH6 for ; Mon, 7 Apr 2014 14:57:44 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A7B5814A1A5 for ; Mon, 7 Apr 2014 14:57:44 +0000 (UTC) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher AES128-SHA256 (128 bits)); Mon, 7 Apr 2014 15:57:39 +0100 Message-ID: <0E1A75E88E4D443FA4AA3BBE9EAE5B21@Tenochtitlan> From: "denis bider \(Bitvise\)" To: "Simon Tatham" , =?iso-8859-1?Q?Niels_=22M=F6ller=22?= Cc: Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE Date: Mon, 7 Apr 2014 08:58:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Note that what I described here is basically the same as "don't reuse channel number for X minutes after channel is closed + ignore request responses for nonexistent channels", but perhaps it's easier to think about it in terms of minimal changes to your existing implementation (use existing channel structure and introduce zombie state), rather than thinking of it as fundamentally changing the way you assign channel numbers. No fundamental changes are actually necessary. -----Original Message----- From: denis bider (Bitvise) Sent: Monday, April 7, 2014 08:51 To: Simon Tatham ; Niels "Möller" Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE I really still think this is a simple issue for the request sender to solve. After CLOSE is received, instead of keeping the channel alive indefinitely, keep it in a zombie state for up to X minutes. Don't make a channel in this zombie state keep a session open, if it would otherwise be closed. If you receive any outstanding responses during zombie state, this lets you recognize them and ignore them and not mix them up with any other channels that might have been opened in the meanwhile. You don't need to know what OpenSSH implementors think because this strategy works regardless of their opinion. You don't need a spec or a community consensus to back this strategy because you don't have to defend this strategy against anyone; it works with all request responders. It simply makes sense to implement. -----Original Message----- From: Simon Tatham Sent: Monday, April 7, 2014 07:45 To: Niels "Möller" Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) wrote: > Can you give us some more details on the problems you have encountered? Background: as I mentioned in a previous message, PuTTY periodically sends a bogus channel request "winadj@putty.projects.tartarus.org", with want_reply set. There is no correct handling defined for this request, so we expect CHANNEL_FAILURE from the server (though we know of at least one server which amusingly sends CHANNEL_SUCCESS :-). We use the timing of that failure message to gauge the round-trip time and tune our window size. All problems I've seen with this race condition have related to these winadj messages. (So the usual workaround if a server is not playing nicely with PuTTY is to suppress winadjes.) The first problem we noticed was precisely your #1: PuTTY would crash out with 'Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 256' type messages, which turned out to be because the server was sending us CHANNEL_FAILURE after CHANNEL_CLOSE whereas we were expecting that CHANNEL_CLOSE meant the server would send no further messages about that channel. We observed this with several servers: my email archives mention Dropbear 0.51 in 2008, OpenSSH 5.1p1 in 2010, and at least one or two SSH servers in embedded devices for which I didn't get full details. Dropbear promptly fixed the problem (changing the server to stop sending post-close CHANNEL_FAILURE). OpenSSH did not, because Damien Miller questioned my analysis of it as a server-side bug on the basis that the spec was unclear (which indeed it is): https://bugzilla.mindrot.org/show_bug.cgi?id=1818 Since OpenSSH didn't make any changes, and since I'd forgotten the previous Dropbear incident at that time, I implemented PuTTY's current workaround, which is to defer _sending_ CHANNEL_CLOSE until it's seen all outstanding CHANNEL_FAILURE messages, so that (from our POV) the channel is still not completely closed at the point when those failures arrive. Unfortunately, it apparently didn't occur to me that that would break interoperation with servers that _don't_ send the outstanding failure messages, because now PuTTY sits and waits for a failure message that will never arrive and so users see hangs on the client side. So, clearly some kind of workaround is needed. But separately from the question of stopgap workarounds while we all sort ourselves out, I'd like to establish a consensus on what the right behaviour _is_, so that SSH implementations can gradually converge on that, and so that in any further situation where a client and a server don't work well together, there's a document to point to which will make it clear which one is wrong, so that we don't have 'no, _you_ fix it' deadlocks between equally stubborn implementors. Responses so far have all said that the consensus is to rule that sending FAILURE after CLOSE is wrong, and that agrees with my original belief (before I started finding out that not everyone agreed). The only people I know who have so far _deliberately_ gone with the other behaviour (in the sense of arguing against fixing it when it was pointed out) are the OpenSSH maintainers. Are any of them reading this? Cheers, Simon -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 7 13:39:27 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5191A084C for ; Mon, 7 Apr 2014 13:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DK1U6hmdOFn for ; Mon, 7 Apr 2014 13:39:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id DC1531A0259 for ; Mon, 7 Apr 2014 13:39:22 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 43BF314A1FD; Mon, 7 Apr 2014 20:39:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 06F7514A1F8 for ; Mon, 7 Apr 2014 20:39:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id P5DSs-bA_94q for ; Mon, 7 Apr 2014 20:39:07 +0000 (UTC) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 5A0CE14A1F7 for ; Mon, 7 Apr 2014 20:39:06 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s37Kd0Pn026036; Mon, 7 Apr 2014 22:39:00 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s37KcxTq026035; Mon, 7 Apr 2014 22:38:59 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE References: Date: Mon, 07 Apr 2014 22:38:59 +0200 In-Reply-To: (Simon Tatham's message of "Mon, 07 Apr 2014 14:45:29 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Simon Tatham writes: > Background: as I mentioned in a previous message, PuTTY periodically > sends a bogus channel request "winadj@putty.projects.tartarus.org", > with want_reply set. There is no correct handling defined for this > request, so we expect CHANNEL_FAILURE from the server (though we know > of at least one server which amusingly sends CHANNEL_SUCCESS :-). I think I've heard of keep-alive requests which work the same way. Anyway, in the work-around category, does this have to be a channel request, or could you use a global request instead? (I think I've heard of servers disconnecting on unknown global requests, but that was some years ago). > OpenSSH did not, because Damien > Miller questioned my analysis of it as a server-side bug on the basis > that the spec was unclear (which indeed it is): > > https://bugzilla.mindrot.org/show_bug.cgi?id=1818 The spec is a bit unclear, but I think your initial interpretation is the one which makes the most sense. Consider the sequence (which I think you mentioned in some comment): A sends CHANNEL_REQUEST (with want_reply set), followed by CHANNEL_CLOSE. B responds with a CHANNEL_CLOSE, followed by a CHANNEL_FAILURE. At the time A receives the CHANNEL_CLOSE, section 5.3 is pretty clear that the channel is dead, and that A may reuse the channel number. So in this scenario the CHANNEL_FAILURE clearly violates the protocol spec. Note that it's not really possible for A to know if B's CHANNEL_CLOSE was a response to A's, or if it was sent while A's messages were still in flight. Now, the question is where to put the blame for this violation. I'd say put the blame on B: After CHANNEL_CLOSE, no further messages relating to the channel can be sent, period. The alternative is to say that it's A's fault: A shouldn't send CHANNEL_CLOSE while it has a pending request. I see two related problems with this alternative: 1. Say A sends a CHANNEL_REQUEST, which B never responds to. Maybe B is misbehaving, or maybe progress on the request simply depends on some process which is stuck or otherwise takes a very long time to complete. Then it will not be possible for A to tear down the channel; since it hasn't seen the response, it would be forbidden to send a CHANNEL_CLOSE. While I think the intention is that either party can initiate teardown by sending CHANNEL_CLOSE any time it likes. 2. It doesn't quite handle the case B generated the CHANNEL_CLOSE independently of A's actions. If B sends the CHANNEL_CLOSE while A's CHANNEL_REQUEST is in flight, the spec still requires A to respond with a CHANNEL_CLOSE. I think it's fairly clear that the intention is that that response should be prompt, with no long delay. On the other hand, there's no limit on how long it might take to respond to a CHANNEL_REQUEST. I'm not sure how the update/errata process works. I think it would make sense to amend section 5.3 to say something like: SSH_MSG_CHANNEL_CLOSE is the final message a party for a channel. If, at the time a party receives a SSH_MSG_CHANNEL_CLOSE, there are some SSH_MSG_CHANNEL_REQUEST that party has sent but not received any replies for, the SSH_MSG_CHANNEL_CLOSE message should be treated as an implicit SSH_MSG_CHANNEL_FAILURE for all outstanding requests The lst piece is actually a bit subtle. If you have received a CHANNEL_REQUEST, and started acting on it at the time you receive a CHANNEL_CLOSE, and the request has any potential side effects, you would need to somehow cancel it. As long as it is still possible that the request might succeed, you can't send the required CHANNEL_CLOSE response. In practice, I think a *short* delay to sort this out is perfectly acceptable. > The only people I know who have so far _deliberately_ gone with the > other behaviour (in the sense of arguing against fixing it when it was > pointed out) are the OpenSSH maintainers. Are any of them reading > this? The way I read that bug log, at least they don't say they won't fix it ever. So the low priority doesn't necessarily mean that they are convinced that there is no openssh bug here. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 10 03:46:20 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE81A067A for ; Thu, 10 Apr 2014 03:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nLcXFD09ntn for ; Thu, 10 Apr 2014 03:46:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 75CDF1A01D5 for ; Thu, 10 Apr 2014 03:46:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B8A8B14A310; Thu, 10 Apr 2014 10:46:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5695114A2FD; Thu, 10 Apr 2014 10:46:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id p56O5dbHQRUL; Thu, 10 Apr 2014 10:46:09 +0000 (UTC) Received: from SSFEXCHEDGE04.srunet.sruad.edu (sruedge04.sru.edu [205.149.70.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A225514A2AC; Thu, 10 Apr 2014 10:46:07 +0000 (UTC) Received: from SSFEXCHCAS01.srunet.sruad.edu (10.99.2.18) by SSFEXCHEDGE04.srunet.sruad.edu (10.99.2.30) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 10 Apr 2014 06:43:30 -0400 Received: from MSFEXCH05.srunet.sruad.edu ([::1]) by SSFEXCHCAS01.srunet.sruad.edu ([10.99.2.18]) with mapi; Thu, 10 Apr 2014 06:40:46 -0400 From: "Smith, Gina M" To: "employeedesk@webmaster.org" Date: Thu, 10 Apr 2014 06:40:43 -0400 Subject: SUSPECT: General web-mail maintenance Thread-Topic: General web-mail maintenance Thread-Index: AQHPVKlSLL8bznvAb0OeYHn5gIeRnQ== Message-ID: <3AAE66988D673246AEB4045835065FD90791D29399@MSFEXCH05.srunet.sruad.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list General web-mail maintenance Dear Account Owner, We want to upgrade all email account scheduled for today as part of our du= ty to strengthen security of your mailbox. CLICK HERE to upgrade your account to Outlook Web Apps 2014. If your settings i= s not updated today, your account will be inactive and cannot send or recei= ve message any longer. Sincerely, IT Helpdesk DEPT From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Apr 11 15:30:02 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F721A0214 for ; Fri, 11 Apr 2014 15:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6ZqeppQUzeD for ; Fri, 11 Apr 2014 15:30:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 448E01A01F7 for ; Fri, 11 Apr 2014 15:30:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6A5CB14A36C; Fri, 11 Apr 2014 22:29:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ABE3514A36B for ; Fri, 11 Apr 2014 22:29:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id UqTCYJnPoI-I for ; Fri, 11 Apr 2014 22:29:54 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 04C9E14A349 for ; Fri, 11 Apr 2014 22:29:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4EAABBEB5 for ; Fri, 11 Apr 2014 22:10:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-N0FVZ2zsrx for ; Fri, 11 Apr 2014 22:10:21 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.23.50]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09CEBBEBE for ; Fri, 11 Apr 2014 22:10:21 +0100 (IST) Message-ID: <53485A3C.7080609@cs.tcd.ie> Date: Fri, 11 Apr 2014 22:10:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: TLS considering an rc4-die-die-die draft References: <534858BA.4080002@cs.tcd.ie> In-Reply-To: <534858BA.4080002@cs.tcd.ie> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <534858BA.4080002@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list FYI. The TLS working group are thinking of adopting an rc4-die-die-die draft, that is to deprecate TLS ciphersuites that use RC4. Thread starts at [1], if you care about RC4 please comment on that list, not here. Someone however asked if SSH's used of RC4 ought also be deprecated at the same time, or not. Which could be done in the same document as the TLS one, or not. What do folks here think about that? Thanks, S. [1] https://www.ietf.org/mail-archive/web/tls/current/msg11932.html From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Apr 12 00:27:39 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015B1A03F9 for ; Sat, 12 Apr 2014 00:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZMd3ni3qLil for ; Sat, 12 Apr 2014 00:27:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id BC9A81A03EA for ; Sat, 12 Apr 2014 00:27:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 65FDC14A2B6; Sat, 12 Apr 2014 07:27:32 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8D8AB14A195 for ; Sat, 12 Apr 2014 07:27:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ZoRjJrDRTdWf for ; Sat, 12 Apr 2014 07:27:28 +0000 (UTC) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 93ED114A162 for ; Sat, 12 Apr 2014 07:27:26 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3C7RK0A016615; Sat, 12 Apr 2014 09:27:20 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3C7RJRS016614; Sat, 12 Apr 2014 09:27:19 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Stephen Farrell Cc: ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> Date: Sat, 12 Apr 2014 09:27:19 +0200 In-Reply-To: <53485A3C.7080609@cs.tcd.ie> (Stephen Farrell's message of "Fri, 11 Apr 2014 22:10:20 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Stephen Farrell writes: > Someone however asked if SSH's used of RC4 ought also be > deprecated at the same time, or not. Which could be done in > the same document as the TLS one, or not. > > What do folks here think about that? I think there's some use for a cipher in ssh which is significantly faster than aes. I'm not following developments as closely as I'd like to, but I think it would be nice with some recommended replacement for such uses, most likely salsa20 or chacha. And I think it would be good to have a spec for using a fast cipher as a traditional cipher in ssh, independent of developments to adopt aead constructions like chacha-poly1305. I don't have a strong opinion on whether or not this is the right time for an explicit deprecation. > [1] https://www.ietf.org/mail-archive/web/tls/current/msg11932.html Is the intention that a conforming implementation must delete all support for rc4? Or is it viewed as acceptable to keep supporting it (if configured by user/administrator) but ensure that the *default* configuration never enables it in the algorithm negotiation? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 01:46:34 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7F81A0299 for ; Sun, 13 Apr 2014 01:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ0zkgsZFLVM for ; Sun, 13 Apr 2014 01:46:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B99D1A029D for ; Sun, 13 Apr 2014 01:46:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8E2CF14A288; Sun, 13 Apr 2014 08:46:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8FA6914A283 for ; Sun, 13 Apr 2014 08:46:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id lOoEndx2-hZf for ; Sun, 13 Apr 2014 08:46:24 +0000 (UTC) Received: from SSHEX02.ad.ssh.com (ip-194-137-52-222.ssh.com [194.137.52.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id A337214A271 for ; Sun, 13 Apr 2014 08:46:23 +0000 (UTC) Received: from [10.13.32.80] (10.13.32.80) by exchange.ssh.com (10.10.10.24) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 13 Apr 2014 10:45:36 +0300 Message-ID: <534A40A2.5090303@ssh.com> Date: Sun, 13 Apr 2014 10:45:38 +0300 From: Tatu Ylonen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Stephen Farrell CC: "ietf-ssh@NetBSD.org" Subject: Re: TLS considering an rc4-die-die-die draft References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-KSE-AntiSpam-Interceptor-Info: trusted connection X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list My understanding is that AES128-SHA1 is about as fast or faster than RC4-MD5 on modern processors due to AES-NI extensions (see http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/open-ssl-performance-paper.pdf). On 12.04.2014 10:27, Niels Möller wrote: > Stephen Farrell writes: > >> Someone however asked if SSH's used of RC4 ought also be >> deprecated at the same time, or not. Which could be done in >> the same document as the TLS one, or not. >> >> What do folks here think about that? > I think there's some use for a cipher in ssh which is significantly > faster than aes. I'm not following developments as closely as I'd like > to, but I think it would be nice with some recommended replacement for > such uses, most likely salsa20 or chacha. And I think it would be good to > have a spec for using a fast cipher as a traditional cipher in ssh, > independent of developments to adopt aead constructions like > chacha-poly1305. > > I don't have a strong opinion on whether or not this is the right time > for an explicit deprecation. > >> [1] https://www.ietf.org/mail-archive/web/tls/current/msg11932.html > Is the intention that a conforming implementation must delete all > support for rc4? Or is it viewed as acceptable to keep supporting it (if > configured by user/administrator) but ensure that the *default* > configuration never enables it in the algorithm negotiation? > > Regards, > /Niels > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 02:25:32 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E3F1A02A5 for ; Sun, 13 Apr 2014 02:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.73 X-Spam-Level: * X-Spam-Status: No, score=1.73 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgm6o2exJfwi for ; Sun, 13 Apr 2014 02:25:31 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id BAF151A02A1 for ; Sun, 13 Apr 2014 02:25:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 96C0A14A2D7; Sun, 13 Apr 2014 09:25:29 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DEF2E14A2CE for ; Sun, 13 Apr 2014 09:25:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id l92zxCu8UUMp for ; Sun, 13 Apr 2014 09:25:26 +0000 (UTC) Received: from baltechnika.lt (mail.baltechnika.lt [88.119.248.7]) by mail.netbsd.org (Postfix) with ESMTP id 340D114A2A7 for ; Sun, 13 Apr 2014 09:25:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by baltechnika.lt (Postfix) with ESMTP id 4E35DCCDA for ; Sun, 13 Apr 2014 09:21:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at baltechnika.lt Received: from baltechnika.lt ([127.0.0.1]) by localhost (baltechnika.lt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9jgS5bbUEKQ for ; Sun, 13 Apr 2014 09:21:25 +0300 (EEST) Received: by baltechnika.lt (Postfix, from userid 5004) id D214F250F3B; Sun, 13 Apr 2014 09:11:33 +0300 (EEST) To: ietf-ssh@netbsd.org Subject: Ms_0!Shopper,bal13 X-PHP-Originating-Script: 5004:eM.php From: unoevaluations Reply-To: anthonykather1@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20140413062041.D214F250F3B@baltechnika.lt> Date: Sun, 13 Apr 2014 09:11:33 +0300 (EEST) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi... We Have a PT/job.5hopping My5tery. we pay $250 per job and we want you to participate. Your job is only to act as a regular customer and conduct normal business, Customer service is valuable. If interested,send the information below. 1. FuII N4ME : 2. FullAdress : 3. Stte | Cty : 4. CodZ!p : 5. Phones Alternate E-mail 6. O.c.c.u.p.a.t.i.o.n Your response would be greatly appreciated. Sincerely, From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 05:14:50 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358B1A01C5 for ; Sun, 13 Apr 2014 05:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvguEbLsmzxt for ; Sun, 13 Apr 2014 05:14:48 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 07E261A0114 for ; Sun, 13 Apr 2014 05:14:48 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A443A14A315; Sun, 13 Apr 2014 12:14:43 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DF92214A2E5 for ; Sun, 13 Apr 2014 12:14:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id RR1A97_mHFBn for ; Sun, 13 Apr 2014 12:14:41 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 32EE114A206 for ; Sun, 13 Apr 2014 12:14:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B5CF4BE57; Sun, 13 Apr 2014 13:14:35 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3LpYbD5mRMG; Sun, 13 Apr 2014 13:14:34 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.72.143]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9E352BE56; Sun, 13 Apr 2014 13:14:34 +0100 (IST) Message-ID: <534A7FAA.4070304@cs.tcd.ie> Date: Sun, 13 Apr 2014 13:14:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Damien Miller CC: ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hiya, On 04/13/2014 12:18 PM, Damien Miller wrote: > OpenSSH will turn RC4 off soon - we're just trying to figure out how > to do it gently enough that working configurations don't suddenly break > yet firmly enough that people actually move to a better cipher. Given the above, I'm guessing that processing this for SSH and TLS might best be done separately, agreed? If so, and if/when someone writes up an SSH rc4-die-die-die draft I'll be happy to sponsor that if doing so seems to be the consensus on this list. Cheers, S. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 05:24:28 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9881A01CA for ; Sun, 13 Apr 2014 05:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RIW84XOx9QK for ; Sun, 13 Apr 2014 05:24:24 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5D1A01D9 for ; Sun, 13 Apr 2014 05:24:24 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8335314A358; Sun, 13 Apr 2014 12:24:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5E9B014A347 for ; Sun, 13 Apr 2014 12:24:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id R7gc6poBXC_J for ; Sun, 13 Apr 2014 12:24:18 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 92D8B14A269 for ; Sun, 13 Apr 2014 12:24:18 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3DBItLc029031; Sun, 13 Apr 2014 21:18:57 +1000 Received: from mailhub.eait.uq.edu.au (taxus.eait.uq.edu.au [130.102.79.56]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3DBItBO023983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Apr 2014 21:18:55 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.14.6/8.14.6) with ESMTP id s3DBIrvm027156; Sun, 13 Apr 2014 21:18:55 +1000 (EST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id AD5C61FB93; Sun, 13 Apr 2014 21:18:53 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id A6D291FB91; Sun, 13 Apr 2014 21:18:53 +1000 (EST) Date: Sun, 13 Apr 2014 21:18:53 +1000 (EST) From: Damien Miller To: Stephen Farrell cc: ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft In-Reply-To: <53485A3C.7080609@cs.tcd.ie> Message-ID: References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> User-Agent: Alpine 2.11 (BSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.73 on 130.102.79.56 X-UQ-FilterTime: 1397387937 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 11 Apr 2014, Stephen Farrell wrote: > > FYI. The TLS working group are thinking of adopting an > rc4-die-die-die draft, that is to deprecate TLS ciphersuites > that use RC4. Thread starts at [1], if you care about RC4 > please comment on that list, not here. > > Someone however asked if SSH's used of RC4 ought also be > deprecated at the same time, or not. Which could be done in > the same document as the TLS one, or not. OpenSSH will turn RC4 off soon - we're just trying to figure out how to do it gently enough that working configurations don't suddenly break yet firmly enough that people actually move to a better cipher. We'll be recommending chacha20-poly1305@openssh.com as a replacment where both ends upport it. https://anongit.mindrot.org/openssh.git/tree/PROTOCOL.chacha20poly1305 -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 05:38:05 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C701A01CA for ; Sun, 13 Apr 2014 05:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n83vcGdAnUcX for ; Sun, 13 Apr 2014 05:38:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6749E1A005E for ; Sun, 13 Apr 2014 05:38:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0C9A314A347; Sun, 13 Apr 2014 12:38:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id F122614A337 for ; Sun, 13 Apr 2014 12:37:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id bOwk7-Nz31_6 for ; Sun, 13 Apr 2014 12:37:57 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id 1F9F814A32E for ; Sun, 13 Apr 2014 12:37:56 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3DBUrOA032478; Sun, 13 Apr 2014 21:30:53 +1000 Received: from mailhub.eait.uq.edu.au (taxus.eait.uq.edu.au [130.102.79.56]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3DBUrsl027814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Apr 2014 21:30:53 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.14.6/8.14.6) with ESMTP id s3DBUqBq002119; Sun, 13 Apr 2014 21:30:52 +1000 (EST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id D95371FB93; Sun, 13 Apr 2014 21:30:52 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id D29E41FB91; Sun, 13 Apr 2014 21:30:52 +1000 (EST) Date: Sun, 13 Apr 2014 21:30:52 +1000 (EST) From: Damien Miller To: Simon Tatham cc: ietf-ssh@netbsd.org Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.73 on 130.102.79.56 X-UQ-FilterTime: 1397388654 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 4 Apr 2014, Simon Tatham wrote: > I think this list still reaches a reasonable number of SSH > implementors. I'd like to see if we can get a consensus on the > following problem. > > Suppose two SSH implementations have a channel open between them. > Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the > want_reply flag set. Party B, meanwhile, independently decides to > initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE. > These two messages cross in the network, so that B receives the > channel request after it's already sent a close message for that > channel. > > Should B send a reply? I agree the spec doesn't make this clear but IMO no. 'A' will receive SSH_MSG_CHANNEL_CLOSE before it would have received any reply and should, based on it, abandon it expectation that a reply will be forthcoming. > Would anyone like to state an opinion on what ought to happen about > this? I can think of two reasonably sensible options: > > (a) Issue a clarifying RFC that resolves the ambiguity by designating > one or other behaviour as correct, and consider implementations > doing the other thing to have a bug requiring a fix. ^^^ this. > (b) Issue an RFC specifying a protocol extension that allows an > implementation to advertise which interpretation it will follow > (since either behaviour is easy to cope with if you know which > one you're talking to). I suppose we'd still have to decide on > the default answer in the absence of such an advertisement. IMO no - it's overkill and not necessary. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 10:11:35 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D091A0159 for ; Sun, 13 Apr 2014 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbDfAbKnLlv9 for ; Sun, 13 Apr 2014 10:11:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 519E91A0202 for ; Sun, 13 Apr 2014 10:11:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7E3BF14A2E5; Sun, 13 Apr 2014 17:11:21 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1926C14A271 for ; Sun, 13 Apr 2014 17:11:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 0sWKMxoaJcQK for ; Sun, 13 Apr 2014 17:11:18 +0000 (UTC) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2527314A263 for ; Sun, 13 Apr 2014 17:11:17 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3DHB0OO014318; Sun, 13 Apr 2014 19:11:00 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3DHAuX8014293; Sun, 13 Apr 2014 19:10:56 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Damien Miller Cc: Stephen Farrell , ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> Date: Sun, 13 Apr 2014 19:10:56 +0200 In-Reply-To: (Damien Miller's message of "Sun, 13 Apr 2014 21:18:53 +1000 (EST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien Miller writes: > OpenSSH will turn RC4 off soon - we're just trying to figure out how > to do it gently enough that working configurations don't suddenly break > yet firmly enough that people actually move to a better cipher. What breakage do you expect? Servers configured to support no other cipher than arcfour, probably from some (possibly misguided) performance argument? > We'll be recommending chacha20-poly1305@openssh.com as a replacment > where both ends upport it. If I have understood correctly, openssh uses the original definition of chacha with 64-bits each for nonce and counter, while recent ietf drafts specify a 96-bit nonce and only 32 bits for the counter. Is that right? I think support for chacha-poly1305 is highly desirable, but it seems a bit messy with specifications still in flux. Best regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 13 18:13:14 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E801A02D7 for ; Sun, 13 Apr 2014 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFYAH_VF9g4j for ; Sun, 13 Apr 2014 18:13:12 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id B19A41A024D for ; Sun, 13 Apr 2014 18:13:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1B5CB14A2CE; Mon, 14 Apr 2014 01:13:07 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 356D814A28E for ; Mon, 14 Apr 2014 01:13:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id MgyXcMqhhw8D for ; Mon, 14 Apr 2014 01:13:04 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 7B48914A27A for ; Mon, 14 Apr 2014 01:13:01 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3E1Ca7L046476; Mon, 14 Apr 2014 11:12:38 +1000 Received: from mailhub.eait.uq.edu.au (taxus.eait.uq.edu.au [130.102.79.56]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id s3E1CaXP021902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Apr 2014 11:12:36 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.14.6/8.14.6) with ESMTP id s3E1CZKs001318; Mon, 14 Apr 2014 11:12:36 +1000 (EST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id E729C1FB93; Mon, 14 Apr 2014 11:12:34 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id E06F51FB91; Mon, 14 Apr 2014 11:12:34 +1000 (EST) Date: Mon, 14 Apr 2014 11:12:34 +1000 (EST) From: Damien Miller To: =?ISO-8859-15?Q?Niels_M=F6ller?= cc: Stephen Farrell , ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft In-Reply-To: Message-ID: References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> User-Agent: Alpine 2.11 (BSO 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.73 on 130.102.79.56 X-UQ-FilterTime: 1397437959 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 13 Apr 2014, Niels M?ller wrote: > Damien Miller writes: > > > OpenSSH will turn RC4 off soon - we're just trying to figure out how > > to do it gently enough that working configurations don't suddenly break > > yet firmly enough that people actually move to a better cipher. > > What breakage do you expect? Servers configured to support no other > cipher than arcfour, probably from some (possibly misguided) performance > argument? People who have "ssh -c arcfour" in their scripts or configurations used non-interactively. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Apr 17 08:41:09 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29601A0138 for ; Thu, 17 Apr 2014 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NzSEwA6Kegw for ; Thu, 17 Apr 2014 08:41:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id A28F61A01CD for ; Thu, 17 Apr 2014 08:41:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id EAFE814A1C6; Thu, 17 Apr 2014 15:40:58 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4424714A1C5 for ; Thu, 17 Apr 2014 15:40:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 3E9t5IMcMhKd for ; Thu, 17 Apr 2014 15:40:56 +0000 (UTC) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mail.netbsd.org (Postfix) with ESMTP id 5845F14A1A9 for ; Thu, 17 Apr 2014 15:40:56 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA28647; Thu, 17 Apr 2014 11:40:55 -0400 (EDT) Date: Thu, 17 Apr 2014 11:40:55 -0400 (EDT) From: Mouse Message-Id: <201404171540.LAA28647@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 17 Apr 2014 11:30:27 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: TLS considering an rc4-die-die-die draft In-Reply-To: References: <534858BA.4080002@cs.tcd.ie> <53485A3C.7080609@cs.tcd.ie> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> Someone however asked if SSH's used of RC4 ought also be deprecated > I think there's some use for a cipher in ssh which is significantly > faster than aes. There are also code-design reasons to want to keep a stream cipher around, though admittedly those can mostly be satisfied by having one for testing but not routine production use. In the immediate future, I will leave arcfour in moussh; I really ned to find the time to read up on the results and figure out what I want to do in the longer term. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Apr 27 08:01:00 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FF71A07A2 for ; Sun, 27 Apr 2014 08:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD52QcHRZxyS for ; Sun, 27 Apr 2014 08:00:58 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5AD1A0651 for ; Sun, 27 Apr 2014 08:00:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5CD0E14A32F; Sun, 27 Apr 2014 15:00:55 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 85E6914A32C for ; Sun, 27 Apr 2014 15:00:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id t1WWoxEdK_l1 for ; Sun, 27 Apr 2014 15:00:52 +0000 (UTC) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id AF5BB14A32A for ; Sun, 27 Apr 2014 15:00:52 +0000 (UTC) Received: by ore.jhcloos.com (Postfix, from userid 10) id 6CC921DECB; Sun, 27 Apr 2014 15:00:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1398610851; bh=N90VkDIZWBh2bjKAluYFfIfmE3eOoULuupbao9U5Fcw=; h=From:To:Subject:Date:From; b=DZtOT0cYVgUeldb3+MhfYse131qEnvUMqm9H7ayTiNnFKSKxJrV7NsXTC2G/wacvk kH8GZFlaiWP511D3HyuW2dZrXYVjkDa23+K8ssQnxYnMDIuc3ImM2V4SFGfkkR7kMi HhGIUzgZJYpek+sOF7RvMO9oTk8xSv9Ym7V331ag= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 30D2760028; Sun, 27 Apr 2014 14:54:46 +0000 (UTC) From: James Cloos To: ietf-ssh@netbsd.org Subject: further pushing ed25519 sshfp User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 27 Apr 2014 10:54:46 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140427:ietf-ssh@netbsd.org::LM1XGu9oH1MAVb3Z:00000000000000000000000000000000000000000qp2Jx Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Can we get an early assignment for algo 4 for ed25519? We have the draft, software which wants to use it, and nothing competing for algo 4. An early assignment should not be controversial. As to the other question, a draft to un-reserve digest type 0 instead to be "raw" would eliminate the issue of whether 256 bit keys should use a 256 bit digest. Admins could decide for themselves. Using 0 for raw is natural; "the null-digest" akin to "the null-cipher". -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 28 08:56:46 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93A1A0842 for ; Mon, 28 Apr 2014 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbbOw9Ivaoel for ; Mon, 28 Apr 2014 08:56:45 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 866AE1A066A for ; Mon, 28 Apr 2014 08:56:45 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6D90014A415; Mon, 28 Apr 2014 15:56:42 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B3FEB14A2AE for ; Mon, 28 Apr 2014 15:56:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id PL8HLtbo3BXG for ; Mon, 28 Apr 2014 15:56:39 +0000 (UTC) Received: from smtp70.ord1c.emailsrvr.com (smtp70.ord1c.emailsrvr.com [108.166.43.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2284114A286 for ; Mon, 28 Apr 2014 15:56:39 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0F5A0148D5E; Mon, 28 Apr 2014 10:39:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id CFF9F1484B7; Mon, 28 Apr 2014 10:39:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: further pushing ed25519 sshfp From: Olafur Gudmundsson In-Reply-To: Date: Mon, 28 Apr 2014 10:39:45 -0400 Cc: ietf-ssh@netbsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Cloos X-Mailer: Apple Mail (2.1510) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Apr 27, 2014, at 10:54 AM, James Cloos wrote: > Can we get an early assignment for algo 4 for ed25519? >=20 > We have the draft, software which wants to use it, and nothing = competing > for algo 4. An early assignment should not be controversial. >=20 > As to the other question, a draft to un-reserve digest type 0 instead = to > be "raw" would eliminate the issue of whether 256 bit keys should use = a > 256 bit digest. Admins could decide for themselves. >=20 > Using 0 for raw is natural; "the null-digest" akin to "the = null-cipher". >=20 > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 >=20 The registry is IETF consensus which means IESG needs to approve = document before IANA allocation.=20 The SOP is that the requesting document says something like this in the = IANA considerations "Value 4 suggested/requested". IANA in my experience honors most of these requests.=20 Given the allocation history of the registry and the fact there is no = other draft that is trying to make an allocation this should happen anyway.=20 Olafur From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 28 09:19:54 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE51A1F20 for ; Mon, 28 Apr 2014 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQjZJeYzqgrH for ; Mon, 28 Apr 2014 09:19:53 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 08D491A08C5 for ; Mon, 28 Apr 2014 09:19:53 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 580FA14A392; Mon, 28 Apr 2014 16:19:50 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 581BA14A37F for ; Mon, 28 Apr 2014 16:19:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id nzldhgvHym-m for ; Mon, 28 Apr 2014 16:19:47 +0000 (UTC) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id B6CCB14A290 for ; Mon, 28 Apr 2014 16:19:47 +0000 (UTC) Received: by ore.jhcloos.com (Postfix, from userid 10) id 49C9E1DDA0; Mon, 28 Apr 2014 16:19:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1398701986; bh=0tRLTmQBb2/hwlj6EqijxjUMq4wiTKVtIaCCAfdLPgM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=M26N6C3q9svTwmm8msW+GYD2cIj9kqyPzaVTGV9W+sYaDpJa0TCFgVCZqJNCTyn5B 60PKUU/RSzjX2BCalQRPVZuv129pCwAsWugLibQIww6UrZIpGAOMjQDw02E36Q1PMk cQx8Kf0Nto2HJSm+DmzPB5wsoDIRCtCCXtNj8cWY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C4C1560022; Mon, 28 Apr 2014 16:14:33 +0000 (UTC) From: James Cloos To: ietf-ssh@netbsd.org Cc: Olafur Gudmundsson Subject: Re: further pushing ed25519 sshfp In-Reply-To: (Olafur Gudmundsson's message of "Mon, 28 Apr 2014 10:39:45 -0400") References: User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 28 Apr 2014 12:14:33 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140428:ietf-ssh@netbsd.org::sG+yEN8M1fxD3kAg:00000000000000000000000000000000000000000SRqT3 X-Hashcash: 1:30:140428:ogud@ogud.com::AgSkPNx3aL2/cBLG:0007wp79 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>>>> "OG" == Olafur Gudmundsson writes: OG> The registry is IETF consensus which means IESG needs to approve OG> document before IANA allocation. OG> The SOP is that the requesting document says something like this in OG> the IANA considerations "Value 4 suggested/requested". There have been early registrations recently (eg, tlsa). And some software authors seem to be waiting for the registration before deploying. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Apr 28 09:51:01 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93661A0A1D for ; Mon, 28 Apr 2014 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzoqj4ZaVWJx for ; Mon, 28 Apr 2014 09:51:00 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 84C681A09B7 for ; Mon, 28 Apr 2014 09:51:00 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id B674314A408; Mon, 28 Apr 2014 16:50:57 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E2E4F14A3D7 for ; Mon, 28 Apr 2014 16:50:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=3yDhOLel; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=K5x7LT0W Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id g3QIoy1vXaIU for ; Mon, 28 Apr 2014 16:50:52 +0000 (UTC) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail.netbsd.org (Postfix) with ESMTP id 2623B14A3BD for ; Mon, 28 Apr 2014 16:50:52 +0000 (UTC) Received: from SUBMAN.elandsys.com ([197.224.135.94]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3SGoOxX007196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Apr 2014 09:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398703836; bh=OjKgVhwErL30S6XkA2be24x9hVFgpi5I+Z8C5Dm7cr0=; h=Date:To:From:Subject:In-Reply-To:References; b=3yDhOLelqKkYpvP2EtUwFc22yeo2hIQ+AKnYJDO0oea+VAgBz9yYHPhLqlknPFAHN vVKHtE+rOyrG8OPGpwM5kqi4DvGPdw68uBgbU1BfFfnnT2eMDLvieNKXBKpcl7y7xi 68y89bO23VhZfrQkjAl9onmNeaocAB6RKhO7kI/Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398703836; i=@elandsys.com; bh=OjKgVhwErL30S6XkA2be24x9hVFgpi5I+Z8C5Dm7cr0=; h=Date:To:From:Subject:In-Reply-To:References; b=K5x7LT0WuJJTEoYrnCojTQIhAB0MeWcyKeTWcWmEOSrTk2BbtAbBqaA+34NSk+Ut0 HZ3Z2PMipgjn2f2GQBLQsS/c9ZZuDPWNwMGEqGbfWT9yPx3qkpzRdoLW/UltXDx9Je 2yrAHvXTGgeqi8dMGuuxrvJqno0JPSPWCUHeR5nc= Message-Id: <6.2.5.6.2.20140428092826.0d8efbd0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 28 Apr 2014 09:49:50 -0700 To: James Cloos , ietf-ssh@NetBSD.org From: S Moonesamy Subject: Re: further pushing ed25519 sshfp In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi James, At 07:54 27-04-2014, James Cloos wrote: >Can we get an early assignment for algo 4 for ed25519? > >We have the draft, software which wants to use it, and nothing competing >for algo 4. An early assignment should not be controversial. I raised the question of the assignment at http://www.ietf.org/mail-archive/web/ietf/current/msg87189.html There were replies from Jari Arkko and Stephen Farrell at: http://www.ietf.org/mail-archive/web/ietf/current/msg87222.html http://www.ietf.org/mail-archive/web/ietf/current/msg87220.html The CFRG meeting is tomorrow ( http://www.ietf.org/mail-archive/web/cfrg/current/msg04448.html ). It should be possible to have an answer within a day or two. >As to the other question, a draft to un-reserve digest type 0 instead to >be "raw" would eliminate the issue of whether 256 bit keys should use a >256 bit digest. Admins could decide for themselves. > >Using 0 for raw is natural; "the null-digest" akin to "the null-cipher". I mentioned that I will be writing a draft a SSHFP issue which was raised during the discussions. I'll include the above as part of the (future) discussion. I need to cover over the IETF RFCs again to see what needs to be done. I am focusing on the assignment first as it should be possible to get an IESG decision by end of May. Regards, S. Moonesamy From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 29 14:23:53 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5081A0950 for ; Tue, 29 Apr 2014 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXJ00wB4hfAn for ; Tue, 29 Apr 2014 14:23:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id D5FEA1A0792 for ; Tue, 29 Apr 2014 14:23:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id F088214A212; Tue, 29 Apr 2014 21:23:48 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4124F14A20B for ; Tue, 29 Apr 2014 21:23:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id F1ONk0fDbkOt for ; Tue, 29 Apr 2014 21:23:35 +0000 (UTC) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by mail.netbsd.org (Postfix) with ESMTP id 1AE9214A209 for ; Tue, 29 Apr 2014 21:23:35 +0000 (UTC) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id EDC453F4007; Tue, 29 Apr 2014 22:05:05 +0200 (CEST) Date: Tue, 29 Apr 2014 22:05:05 +0200 (CEST) Message-Id: <20140429.220505.221212226.mbj@tail-f.com> To: ietf-ssh@NetBSD.org Cc: netmod@ietf.org Subject: SSH keys - draft-ietf-netmod-system-mgmt From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, The NETMOD WG has produced draft-ietf-netmod-system-mgmt-15, which contains a YANG data model for system management. This document today enters a second IETF Last Call. Among other things, it has a data model for the definition of SSH public keys for local users on a device. Stephen Farrell suggested that this list might be able to help us with an SSH-specific question. We would be very grateful for any expert help. First some background. The data model in question has this structure (objects unrelated to SSH keys removed) +--rw user* [name] +--rw name string +--rw ssh-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary This means that there is a list of users, identified by name. Each user has a list of public SSH keys, identified by an arbitrary name. Zooming in on the ssh-key list, it looks like this: list ssh-key { key name; description "A list of public SSH keys for this user."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; leaf name { type string; description "An arbitrary name for the ssh key."; } leaf algorithm { type string; mandatory true; description "The public key algorithm name for this ssh key. Valid values are the values in the IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; reference "IANA Secure Shell (SSH) Protocol Parameters registry, Public Key Algorithm Names"; } leaf key-data { type binary; mandatory true; description "The binary key data for this ssh key."; } } Now to the problem. During implementation of ssh key handling, we realized that the description of these objects need at least some clarification. The intention was that the separation of the key with two leafs, "algorithm" and "key-data" makes it easy to cut-and-paste from keys generated with ssh-keygen etc. (The encoding of type binary in YANG is base64, which happen to match the key format. So the operator can set the "algorithm" and pase the base64 encoded blob into "key-data".) First of all, it is not entirely clear what goes into the "key-data" leaf. Common file formats (open ssh proprietary, RFC4716) follow the same rules; defined in RFC4716: The body of a public key file is the base64 encoded ([RFC2045]) public key data as specified by [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data The open ssh internal format is this: e.g.: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... The base64 blob is encoded as described above, i.e. it contains the string "ssh-rsa", even though this is already specified at the start of the line. So this format is redundant, and it seems the implementation detects and rejects keys that have different values for the and the public key format identifier. The RFC 4716 format does not have this redundancy: ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAADAQABAAABAQDBNX... ... ---- END SSH2 PUBLIC KEY ---- So we have some options: 1) Clarify that the leaf "key-data" contains: string certificate or public key format identifier byte[n] key/certificate data This allows for simple copy-and-paste from normal open ssh and rfc4716 files. However, if we also keep the leaf algorithm, we need to specify what happens if the leaf algorithm has a value that is different from the value embedded in the key blob. 2) Like 1, but remove the "leaf algorithm". 3) Keep "leaf algorithm" and specify that the leaf "key-data" contains: byte[n] key/certificate data This is NOT copy-and-paste friendly and probably pretty confusing to operators. Some other issues, probably less important. o If we do 1 or 2 above, is the name "key-data" really correct; shouldn't it be changed to just "key", in order to use the same terminology as RFC 4253: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data Which says that a "key" is encoded as "format id" + "key data". o Should list "ssh-key" be called "ssh-public-key"? The description says it is public keys only, so shouldn't this be reflected in the name of the list? We are leaning towards option 2 above, and would very much appreciate any comments on this matter! /martin From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Apr 29 23:49:25 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845351A6EE5 for ; Tue, 29 Apr 2014 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KpMtOtvvC1m for ; Tue, 29 Apr 2014 23:49:22 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id E04C51A6EE0 for ; Tue, 29 Apr 2014 23:49:21 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2675914A21C; Wed, 30 Apr 2014 06:49:20 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 4A8BD14A212 for ; Wed, 30 Apr 2014 06:49:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id J_j8HU-dCFyJ for ; Wed, 30 Apr 2014 06:49:15 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4457114A1DD for ; Wed, 30 Apr 2014 06:49:13 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3U6n732024476; Wed, 30 Apr 2014 08:49:07 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3U6n6ZQ024475; Wed, 30 Apr 2014 08:49:06 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Martin Bjorklund Cc: ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt References: <20140429.220505.221212226.mbj@tail-f.com> Date: Wed, 30 Apr 2014 08:49:06 +0200 In-Reply-To: <20140429.220505.221212226.mbj@tail-f.com> (Martin Bjorklund's message of "Tue, 29 Apr 2014 22:05:05 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Martin Bjorklund writes: > 1) Clarify that the leaf "key-data" contains: > > string certificate or public key format identifier > byte[n] key/certificate data > > This allows for simple copy-and-paste from normal open ssh and > rfc4716 files. > > However, if we also keep the leaf algorithm, we need to specify > what happens if the leaf algorithm has a value that is different > from the value embedded in the key blob. Right, eliminating this redundancy makes things simpler. > 2) Like 1, but remove the "leaf algorithm". I'm not sure I understand the context, but this sounds like the best option to me. If one wants a human-readable algorithm identifier, one could include that in the name field (but ideally, any tools handling this data should be able to extract the algorithm id from the key blob). > 3) Keep "leaf algorithm" and specify that the leaf "key-data" contains: > > byte[n] key/certificate data > > This is NOT copy-and-paste friendly and probably pretty > confusing to operators. I would recommend *not* picking apart the ssh key (unless you really want to convert it to some other reasonable representation, say, an spki-style s-expression). > Some other issues, probably less important. > > o If we do 1 or 2 above, is the name "key-data" really correct; > shouldn't it be changed to just "key", in order to use the same > terminology as RFC 4253: Makes sense. > o Should list "ssh-key" be called "ssh-public-key"? > > The description says it is public keys only, so shouldn't this be > reflected in the name of the list? I think it would make more sense to have a name that reflects the *purpose* of the list of keys, rather than just the data type. E.g., if it's authorization keys for logging in to the users account, it could be "authorized-ssh-keys" or something like that. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 09:33:11 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8A1A702F for ; Wed, 30 Apr 2014 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWx-yOU6HnEQ for ; Wed, 30 Apr 2014 09:33:11 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 063171A8824 for ; Wed, 30 Apr 2014 09:33:11 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 197ED14A263; Wed, 30 Apr 2014 16:33:09 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 54E7414A25F for ; Wed, 30 Apr 2014 16:33:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 89uW0cxCnGbp for ; Wed, 30 Apr 2014 16:33:05 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 90DC214A258 for ; Wed, 30 Apr 2014 16:33:04 +0000 (UTC) Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UGWpR6024221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 12:32:52 -0400 (EDT) Message-ID: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt From: Jeffrey Hutzelman To: Niels =?ISO-8859-1?Q?M=F6ller?= Cc: jhutz@cmu.edu, Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org Date: Wed, 30 Apr 2014 12:32:50 -0400 In-Reply-To: References: <20140429.220505.221212226.mbj@tail-f.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > However, if we also keep the leaf algorithm, we need to specify > > what happens if the leaf algorithm has a value that is different > > from the value embedded in the key blob. > > Right, eliminating this redundancy makes things simpler. It would, except you can't eliminate it. The second copy of the algorithm name is part of the key data format for _certain public key algorithms_, but not necessarily for all of them. The right thing here is to leave it as defined - the "algorithm" is a string naming the public key algorithm, and the "key-data" is an _opaque_ base64 blob. The fact that for certain kinds of keys the opaque blob happens to contain a copy of the algorithm name is irrelevant. As for what happens when they're different -- it doesn't work! If you say you're providing a key for one algorithm and actually provide key data for a different one, it's simply not going to work. You could check when setting a key that the provided key data is valid for the specified algorithm, but I would very strongly recommend against that. Doing so requires that whatever's doing the validation understand all possible key algorithms, which is impossible, since public key algorithm names are a vendor-extensible namespace. > I think it would make more sense to have a name that reflects the > *purpose* of the list of keys, rather than just the data type. E.g., if > it's authorization keys for logging in to the users account, it could be > "authorized-ssh-keys" or something like that. Yes. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 09:44:38 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020321A0910 for ; Wed, 30 Apr 2014 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joKnv-U7mB9A for ; Wed, 30 Apr 2014 09:44:36 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 642B21A08E8 for ; Wed, 30 Apr 2014 09:44:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 9040F14A251; Wed, 30 Apr 2014 16:44:33 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id DF24214A1D3 for ; Wed, 30 Apr 2014 16:44:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id AinU74d0dnk5 for ; Wed, 30 Apr 2014 16:44:29 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 0113114A1CE for ; Wed, 30 Apr 2014 16:44:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7EED0BE77; Wed, 30 Apr 2014 17:44:23 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+0FPanXWooZ; Wed, 30 Apr 2014 17:44:23 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 59275BE68; Wed, 30 Apr 2014 17:44:23 +0100 (IST) Message-ID: <53612866.5090103@cs.tcd.ie> Date: Wed, 30 Apr 2014 17:44:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: S Moonesamy , James Cloos , ietf-ssh@NetBSD.org Subject: Re: further pushing ed25519 sshfp References: <6.2.5.6.2.20140428092826.0d8efbd0@elandnews.com> In-Reply-To: <6.2.5.6.2.20140428092826.0d8efbd0@elandnews.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list FYI, based on last night's (in my TZ;-) CFRG session I'll be starting an IETF LC for SM's draft. Be great to get any comments on that if you have 'em Ta, S. On 28/04/14 17:49, S Moonesamy wrote: > Hi James, > At 07:54 27-04-2014, James Cloos wrote: >> Can we get an early assignment for algo 4 for ed25519? >> >> We have the draft, software which wants to use it, and nothing competing >> for algo 4. An early assignment should not be controversial. > > I raised the question of the assignment at > http://www.ietf.org/mail-archive/web/ietf/current/msg87189.html There > were replies from Jari Arkko and Stephen Farrell at: > > http://www.ietf.org/mail-archive/web/ietf/current/msg87222.html > http://www.ietf.org/mail-archive/web/ietf/current/msg87220.html > > The CFRG meeting is tomorrow ( > http://www.ietf.org/mail-archive/web/cfrg/current/msg04448.html ). It > should be possible to have an answer within a day or two. > >> As to the other question, a draft to un-reserve digest type 0 instead to >> be "raw" would eliminate the issue of whether 256 bit keys should use a >> 256 bit digest. Admins could decide for themselves. >> >> Using 0 for raw is natural; "the null-digest" akin to "the null-cipher". > > I mentioned that I will be writing a draft a SSHFP issue which was > raised during the discussions. I'll include the above as part of the > (future) discussion. I need to cover over the IETF RFCs again to see > what needs to be done. I am focusing on the assignment first as it > should be possible to get an IESG decision by end of May. > > Regards, > S. Moonesamy > > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 11:14:57 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B37F1A8840 for ; Wed, 30 Apr 2014 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baRh9PKgEghl for ; Wed, 30 Apr 2014 11:14:56 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 47A851A04B6 for ; Wed, 30 Apr 2014 11:14:56 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2C3E414A200; Wed, 30 Apr 2014 18:14:52 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 05EBC14A1DA for ; Wed, 30 Apr 2014 18:14:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id yqTNyPy9xQFd for ; Wed, 30 Apr 2014 18:14:47 +0000 (UTC) Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 303EA14A193 for ; Wed, 30 Apr 2014 18:14:46 +0000 (UTC) Received: from [192.168.1.132] (50-73-160-70-pennsylvania.hfc.comcastbusiness.net [50.73.160.70]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s3UIEKn9024313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 14:14:21 -0400 (EDT) Message-ID: <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu> Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt From: Jeffrey Hutzelman To: Juergen Schoenwaelder Cc: jhutz@cmu.edu, Niels =?ISO-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org Date: Wed, 30 Apr 2014 14:14:19 -0400 In-Reply-To: <20140430175031.GC31746@elstar.local> References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140430175031.GC31746@elstar.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote: > On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > > However, if we also keep the leaf algorithm, we need to specify > > > > what happens if the leaf algorithm has a value that is different > > > > from the value embedded in the key blob. > > > > > > Right, eliminating this redundancy makes things simpler. > > > > It would, except you can't eliminate it. The second copy of the > > algorithm name is part of the key data format for _certain public key > > algorithms_, but not necessarily for all of them. > > > > Hm. Are you saying RFC 4716 is broken or only applicable to certain > subset of public key algorithms? In which case would the public key > not follow [RFC4253], Section 6.6: > > string certificate or public key format identifier > byte[n] key/certificate data > > I am just trying to understand this. Section 6.6 is actually quite specific on this: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which each begin with a fixed string that is the same as the key type name, and two more which are unfortunately rather vague, but which I don't think are commonly used. I seem to recall this being an issue in the past, because someone made an assumption that keys would always be self-describing when in fact they were not. Unfortunately, I no longer remember the exact circumstances. But yes, I believe RFC4716 is broken, because it relies on the encoding described above, rather than being consistent with the requirement "The key type MUST always be explicitly known." IMHO, things that are not implementations of SSH should not need to be aware of SSH's encoding or of the details of particular public key formats. They should treat the opaque key data as opaque, and separate from the key type. -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 12:16:49 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D0B1A094A for ; Wed, 30 Apr 2014 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrH7u8IDXsXd for ; Wed, 30 Apr 2014 12:16:49 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 218591A8874 for ; Wed, 30 Apr 2014 12:16:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3EDFB14A26D; Wed, 30 Apr 2014 19:16:45 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C9D4514A26C for ; Wed, 30 Apr 2014 19:16:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id LgFEeXldtpBo for ; Wed, 30 Apr 2014 19:16:40 +0000 (UTC) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id EA04B14A257 for ; Wed, 30 Apr 2014 19:16:39 +0000 (UTC) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 728FB10B3; Wed, 30 Apr 2014 19:50:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3VhCXqX4eqPy; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBC8820017; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TDJ6NsIFH4h6; Wed, 30 Apr 2014 19:50:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9176C20013; Wed, 30 Apr 2014 19:50:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE4802CC6EFB; Wed, 30 Apr 2014 19:50:31 +0200 (CEST) Date: Wed, 30 Apr 2014 19:50:31 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Cc: Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt Message-ID: <20140430175031.GC31746@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jeffrey Hutzelman , Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.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: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > However, if we also keep the leaf algorithm, we need to specify > > > what happens if the leaf algorithm has a value that is different > > > from the value embedded in the key blob. > > > > Right, eliminating this redundancy makes things simpler. > > It would, except you can't eliminate it. The second copy of the > algorithm name is part of the key data format for _certain public key > algorithms_, but not necessarily for all of them. > Hm. Are you saying RFC 4716 is broken or only applicable to certain subset of public key algorithms? In which case would the public key not follow [RFC4253], Section 6.6: string certificate or public key format identifier byte[n] key/certificate data I am just trying to understand this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 12:20:16 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8731A884D for ; Wed, 30 Apr 2014 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxAmFVqMpTNy for ; Wed, 30 Apr 2014 12:20:15 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id D30C21A096C for ; Wed, 30 Apr 2014 12:20:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C7AA114A1C0; Wed, 30 Apr 2014 19:20:12 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A153214A1BF for ; Wed, 30 Apr 2014 19:20:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id ivvUirA14hnA for ; Wed, 30 Apr 2014 19:20:06 +0000 (UTC) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 90DCD14A141 for ; Wed, 30 Apr 2014 19:20:06 +0000 (UTC) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0C35FED; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id y2XWrsnN-GZl; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0571220017; Wed, 30 Apr 2014 21:20:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zXrI6nTGUqmj; Wed, 30 Apr 2014 21:20:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1E9A20013; Wed, 30 Apr 2014 21:20:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 238402CC6F9A; Wed, 30 Apr 2014 21:20:00 +0200 (CEST) Date: Wed, 30 Apr 2014 21:20:00 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Cc: Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt Message-ID: <20140430192000.GA31986@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Jeffrey Hutzelman , Niels =?iso-8859-1?Q?M=F6ller?= , Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <20140430175031.GC31746@elstar.local> <1398881659.20380.39.camel@destiny.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: <1398881659.20380.39.camel@destiny.pc.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Wed, Apr 30, 2014 at 02:14:19PM -0400, Jeffrey Hutzelman wrote: > On Wed, 2014-04-30 at 19:50 +0200, Juergen Schoenwaelder wrote: > > On Wed, Apr 30, 2014 at 12:32:50PM -0400, Jeffrey Hutzelman wrote: > > > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: > > > > > However, if we also keep the leaf algorithm, we need to specify > > > > > what happens if the leaf algorithm has a value that is different > > > > > from the value embedded in the key blob. > > > > > > > > Right, eliminating this redundancy makes things simpler. > > > > > > It would, except you can't eliminate it. The second copy of the > > > algorithm name is part of the key data format for _certain public key > > > algorithms_, but not necessarily for all of them. > > > > > > > Hm. Are you saying RFC 4716 is broken or only applicable to certain > > subset of public key algorithms? In which case would the public key > > not follow [RFC4253], Section 6.6: > > > > string certificate or public key format identifier > > byte[n] key/certificate data > > > > I am just trying to understand this. > > Section 6.6 is actually quite specific on this: > > The key type MUST always be explicitly known (from algorithm > negotiation or some other source). It is not normally included in > the key blob. > > > It then goes on to define two key types ("ssh-dss" and "ssh-rsa") which > each begin with a fixed string that is the same as the key type name, > and two more which are unfortunately rather vague, but which I don't > think are commonly used. Well, but the text in section 6.6 also says this (right after the text you quoted): : Certificates and public keys are encoded as follows: : : string certificate or public key format identifier : byte[n] key/certificate data This text does not look conditional and perhaps this is where the confusion comes from? For me, as a reader who has no prior involvement in this, these two paragraphs look a bit like a contradiction... > I seem to recall this being an issue in the past, because someone made > an assumption that keys would always be self-describing when in fact > they were not. Unfortunately, I no longer remember the exact > circumstances. But yes, I believe RFC4716 is broken, because it relies > on the encoding described above, rather than being consistent with the > requirement "The key type MUST always be explicitly known." OK. I am happy to follow you advice to keep the algorithm type leaf. > IMHO, things that are not implementations of SSH should not need to be > aware of SSH's encoding or of the details of particular public key > formats. They should treat the opaque key data as opaque, and separate > from the key type. Yes, I think we agree. I do not expect a NETCONF server to try to validate whether the key blob is valid. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 13:06:40 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CAA1A097D for ; Wed, 30 Apr 2014 13:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGtga6LgsifL for ; Wed, 30 Apr 2014 13:06:39 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE41A0972 for ; Wed, 30 Apr 2014 13:06:39 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 76CED14A247; Wed, 30 Apr 2014 20:06:31 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2C2CD14A233 for ; Wed, 30 Apr 2014 20:06:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id XPBNJ6KDdRwZ for ; Wed, 30 Apr 2014 20:06:27 +0000 (UTC) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1843614A247 for ; Wed, 30 Apr 2014 20:06:25 +0000 (UTC) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s3UK68KY009766; Wed, 30 Apr 2014 22:06:08 +0200 (MEST) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s3UK66oK009765; Wed, 30 Apr 2014 22:06:06 +0200 (MEST) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Jeffrey Hutzelman Cc: Martin Bjorklund , ietf-ssh@NetBSD.org, netmod@ietf.org Subject: Re: SSH keys - draft-ietf-netmod-system-mgmt References: <20140429.220505.221212226.mbj@tail-f.com> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> Date: Wed, 30 Apr 2014 22:06:06 +0200 In-Reply-To: <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 30 Apr 2014 12:32:50 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Jeffrey Hutzelman writes: > On Wed, 2014-04-30 at 08:49 +0200, Niels Möller wrote: >> > However, if we also keep the leaf algorithm, we need to specify >> > what happens if the leaf algorithm has a value that is different >> > from the value embedded in the key blob. >> >> Right, eliminating this redundancy makes things simpler. > > It would, except you can't eliminate it. Hmm. I think you're right. So then then the "algorithm" leaf would be the name being used in algorithm negotiation and the like, and the "key" leaf would be the key blob. The key blob typically starts with a string containing the algorithm identifier, but nothing but the ssh implementation is expected to care about that detail. So then the right choice is 1), : 1) Clarify that the leaf "key-data" contains: : : string certificate or public key format identifier : byte[n] key/certificate data : : This allows for simple copy-and-paste from normal open ssh and : rfc4716 files. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Apr 30 14:21:38 2014 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105C81A093B for ; Wed, 30 Apr 2014 14:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4rZxSIK0Ud5 for ; Wed, 30 Apr 2014 14:21:35 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id C461B1A08B5 for ; Wed, 30 Apr 2014 14:21:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A46C714A258; Wed, 30 Apr 2014 21:21:31 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A72FF14A257 for ; Wed, 30 Apr 2014 21:21:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=jhcloos.com Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.NetBSD.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id YwCXs9-zqAVt for ; Wed, 30 Apr 2014 21:21:29 +0000 (UTC) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1AAC414A251 for ; Wed, 30 Apr 2014 21:21:28 +0000 (UTC) Received: by ore.jhcloos.com (Postfix, from userid 10) id 880DD1E047; Wed, 30 Apr 2014 21:21:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1398892887; bh=1AkHLjktAzHPX871Sv7sUrtbdjpP8a0AVvoeXr62kb0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rXX6yS8qDR2ShIVKupNuT3n93uwgNHWFpAxEpGtHyVrhq3gtw/6Y+5r01BTIiV4tS RowLp7TzzJs8RC5YGG7qL74f7UwiHmL2kcPkAK1GEb2GEZcKWz1Fmd3xsA0tk0dVLT AaQi26ZeG9a+b6yL92cvNNzoIucI4Tns198l2uac= Received: by carbon.jhcloos.org (Postfix, from userid 500) id F161D6001D; Wed, 30 Apr 2014 21:14:08 +0000 (UTC) From: James Cloos To: Stephen Farrell Cc: S Moonesamy , ietf-ssh@NetBSD.org Subject: Re: further pushing ed25519 sshfp In-Reply-To: <53612866.5090103@cs.tcd.ie> (Stephen Farrell's message of "Wed, 30 Apr 2014 17:44:22 +0100") References: <6.2.5.6.2.20140428092826.0d8efbd0@elandnews.com> <53612866.5090103@cs.tcd.ie> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 30 Apr 2014 17:14:08 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140430:stephen.farrell@cs.tcd.ie::KRU5bcoTrDPjkun1:00000000000000000000000000000000000Cmxsf X-Hashcash: 1:30:140430:sm+ietf@elandsys.com::KHh3F8TGToFXZLBL:0000000000000000000000000000000000000000m26V1 X-Hashcash: 1:30:140430:ietf-ssh@netbsd.org::zH6U5Iu3FVGoaYoZ:00000000000000000000000000000000000000000Dovyt Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >>>>> "SF" == Stephen Farrell writes: SF> FYI, based on last night's (in my TZ;-) CFRG session I'll be SF> starting an IETF LC for SM's draft. Cool. SF> Be great to get any comments on that if you have 'em There isn't much to say; it looks complete and concise. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6