From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Mar 3 22:47:12 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A954421F859C for ; Sun, 3 Mar 2013 22:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.745 X-Spam-Level: * X-Spam-Status: No, score=1.745 tagged_above=-999 required=5 tests=[HOST_EQ_PE=1.445, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmD16Ve5g9Di for ; Sun, 3 Mar 2013 22:47:11 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2757F21F856D for ; Sun, 3 Mar 2013 22:47:08 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 775CA14A1DD; Mon, 4 Mar 2013 06:47: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 BBE7D14A1DB for ; Mon, 4 Mar 2013 06:47: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 Y91eg8sSDsTk for ; Mon, 4 Mar 2013 06:47:05 +0000 (UTC) Received: from UAPMAIL4.uap.edu.pe (uapmail.uap.edu.pe [200.37.174.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 00C6914A1D7 for ; Mon, 4 Mar 2013 06:47:04 +0000 (UTC) Received: from UAPMAIL4.uap.edu.pe ([fe80::9d69:70c9:e380:f27b]) by UAPMAIL4.uap.edu.pe ([fe80::9d69:70c9:e380:f27b%11]) with mapi id 14.01.0438.000; Mon, 4 Mar 2013 00:40:40 -0500 From: Admision Cajamarca Subject: =?iso-8859-1?Q?=A1ATENCI=D3N!_Buz=F3n_deshabilitado!?= Thread-Topic: =?iso-8859-1?Q?=A1ATENCI=D3N!_Buz=F3n_deshabilitado!?= Thread-Index: Ac4Ymr45KESAuV59SX6EU0QQerhOtA== Date: Mon, 4 Mar 2013 05:40:40 +0000 Message-ID: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.128.16.80] 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 To: undisclosed-recipients:; Su cuenta ha sido bloqueada temporalmente desactivada. Este bloque puede se= r causado por el env=EDo de mensajes que activan los filtros de correo no d= eseado, o por tener demasiados destinatarios en un correo electr=F3nico. Le= animamos a que haga clic en este enlace y verificar su cuenta de correo el= ectr=F3nico inmediatamente http://www.afaes.net/members/use/webform1/form1.= html De lo contrario, esta cuenta de correo electr=F3nico deber=E1 estar permane= ntemente desactivado en las 24 horas siguientes. Atenci=F3n: verificar haci= endo clic y llenar las columnas vac=EDas aqu=ED http://www.afaes.net/member= s/use/webform1/form1.html Pedimos disculpas por las molestias. Gracias, El equipo de Correo Administrativo From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 6 19:52:26 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B721F8824 for ; Wed, 6 Mar 2013 19:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIiSowRYmuZ1 for ; Wed, 6 Mar 2013 19:52:26 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50421F881A for ; Wed, 6 Mar 2013 19:52:23 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id B5FA514A36D; Thu, 7 Mar 2013 03:52: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 6140514A36A for ; Thu, 7 Mar 2013 03:52:12 +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 B5QZFV75jIDU for ; Thu, 7 Mar 2013 03:52:11 +0000 (UTC) Received: from allman.clausal.com (ip-194-137-52-208.ssh.com [194.137.52.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6C0F514A329 for ; Thu, 7 Mar 2013 03:52:11 +0000 (UTC) Received: from [192.168.43.158] (md32836d0.tmodns.net [208.54.40.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by allman.clausal.com (Postfix) with ESMTPSA id D9208496001; Thu, 7 Mar 2013 04:42:36 +0200 (EET) From: Tatu Ylonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8 Date: Thu, 7 Mar 2013 04:34:02 +0200 Message-Id: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com> Cc: ietf-ssh@netbsd.org To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list We will be having a side meeting on SSH Key Management Best Practice at = the IETF on Monday, 13:00 to 14:00. The assigned room is Boca 8. = Welcome! I will present draft-ylonen-sshkeybcp-00 = (http://tools.ietf.org/html/draft-ylonen-sshkeybcp-00) and we should = have plenty of time for discussion. The draft illustrates threats due = to poorly managed SSH user keys, provides a process for getting from an = unmanaged environment into a managed environment, and presents = recommendations for ongoing management and continuous monitoring. It = also discusses the residual risks if any of the remediation steps are = not taken. The draft focuses on managing large environments (100 - = 100000+ servers) and is targeted at security architects, Unix/Linux = operations managers, policy makers, and auditors. It also briefly = addresses other technologies for automated access, as the several of the = threats also apply to them. As background, the SSH protocol is widely used for managing Unix/Linux = servers, telecommunications networks, routers, and many embedded = systems. It is also widely used for file transfers (particularly with = the SFTP protocol), and many systems management, security, and audit = tools use it to access managed systems. Many organizations have = thousands of custom scripts using SSH to perform administrative tasks = and to automatically transfer data between applications. A lot of these = uses are fully automated and run without an interactive user; keys = (without passphrases) are usually used for authentication in those = cases. Many large organizations have accumulated hundreds of thousands, in some = cases millions, of authorized SSH user keys on their servers over the = years. These keys have never been changed. Administrators don't know = what each key is used for and cannot remove these keys because they = don't know what applications would break if they remove a key. System = administrators can use key-based access to circumvent privileged access = management systems, creating essentially permanent backdoors to = production servers. SSH user keys are already collected and used by = various attack tools, and can help malware spread throughout an = organization's server infrastructure in minutes. The problem is largely = unrecognized and is not understood by compliance auditors and IT risk = managers. The problem is not about managing keys but about managing access. SSH = user keys are generally strong enough. The problem is that = organizations do not know who can access what and many do not control = who can add new authorized keys, do not audit key-based access to = servers, and do not control what can be done with each key. Generally, = organizations do not properly terminate access when an employee leaves = or changes roles. Many organizations permit automated access from = low-security hosts (e.g., development machines) to critical production = systems. The draft documents the current best practice of managing SSH user keys. = It is not a protocol document, but rather presents risks and = recommendations for proper process and policy. Feedback on the draft is very welcome regardless of whether you will be = able to attend the meeting. Please send comments directly to me. We = want the draft to make a reasonable compromise between security and = implementability in an organization. The plan is to eventually publish = a future version of the document as a Best Current Practice. Best regards, Tatu Ylonen From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 13 14:11:55 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7237E21F8E50 for ; Wed, 13 Mar 2013 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDMPbOmRvRHv for ; Wed, 13 Mar 2013 14:11: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 9EC8221F8E5D for ; Wed, 13 Mar 2013 14:11:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 06FF114A2F7; Wed, 13 Mar 2013 21:11: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 0313914A2F6 for ; Wed, 13 Mar 2013 21:11: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 en9-zpp5whpr for ; Wed, 13 Mar 2013 21:11:39 +0000 (UTC) Received: from wfsd-em.wfsd.k12.ny.us (wfsd-em.wfsd.k12.ny.us [24.38.123.8]) by mail.netbsd.org (Postfix) with ESMTP id 760F414A2C2 for ; Wed, 13 Mar 2013 21:11:38 +0000 (UTC) Received: from wfsd-em.wfsd.k12.ny.us (localhost [127.0.0.1]) by wfsd-em.wfsd.k12.ny.us (Postfix) with ESMTP id 6F0C662564; Wed, 13 Mar 2013 15:54:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at lscom.net Received: from wfsd-em.wfsd.k12.ny.us ([127.0.0.1]) by wfsd-em.wfsd.k12.ny.us (wfsd-em.wfsd.k12.ny.us [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg-6o2srLlgr; Wed, 13 Mar 2013 15:54:29 -0400 (EDT) Received: from WFMAIL3.wfsd.k12.ny.us (wfmail3.wfsd.k12.ny.us [10.50.5.18]) by wfsd-em.wfsd.k12.ny.us (Postfix) with ESMTP id 847C26248D; Wed, 13 Mar 2013 15:54:27 -0400 (EDT) Received: from WFMAIL1.wfsd.k12.ny.us ([10.50.5.16]) by WFMAIL3.wfsd.k12.ny.us ([fe80::f58d:90d0:be1:2a2f%10]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 15:52:46 -0400 From: "Schick, Carolyn" Subject: Reach me directly on this Email id: vincenthong182@yahoo.com.hk Thread-Topic: Reach me directly on this Email id: vincenthong182@yahoo.com.hk Thread-Index: Ac4gI0pxykQpfRQPRHqQVwE83rXwBQ== Date: Wed, 13 Mar 2013 19:52:44 +0000 Message-ID: <447B3BF1737E5140B4240F004425E2004CDCA9ED@WFMAIL1.wfsd.k12.ny.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [180.215.158.144] 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 To: undisclosed-recipients:; I have an offer for you if interested get back to me soonest. on this email= id: vincenthong182@yahoo.com.hk From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Mar 27 02:44:39 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C021F90A9 for ; Wed, 27 Mar 2013 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_60=1, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54OQs0rhqIeY for ; Wed, 27 Mar 2013 02:44:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A84B21F8FDD for ; Wed, 27 Mar 2013 02:44:38 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5F7A614A488; Wed, 27 Mar 2013 09:44: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 954C914A47C for ; Wed, 27 Mar 2013 09:44: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 IZ7zSaaw_Cjh for ; Wed, 27 Mar 2013 09:44:34 +0000 (UTC) Received: from agero.humv.es (agero.humv.es [193.146.74.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 7FC1114A46D for ; Wed, 27 Mar 2013 09:44:32 +0000 (UTC) Received: from ropero.intranet.humv.es (ropero [172.17.254.15]) by agero.humv.es (8.13.1/8.13.1) with ESMTP id r2D8qoHX002770; Wed, 13 Mar 2013 09:53:07 +0100 Received: from ropero.intranet.humv.es (localhost [127.0.0.1]) by ropero.intranet.humv.es (8.13.1/8.13.1) with ESMTP id r2D8qnIO017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2013 09:52:49 +0100 Received: (from apache@localhost) by ropero.intranet.humv.es (8.13.1/8.13.1/Submit) id r2D8qaAd016931; Wed, 13 Mar 2013 09:52:36 +0100 X-Authentication-Warning: ropero.intranet.humv.es: apache set sender to csif@humv.es using -f Received: from 82.128.16.141 (SquirrelMail authenticated user e639); by correo.humv.es with HTTP; Wed, 13 Mar 2013 09:52:36 +0100 (CET) Message-ID: <51267.82.128.16.141.1363164756.squirrel@correo.humv.es> Date: Wed, 13 Mar 2013 09:52:36 +0100 (CET) Subject: =?iso-8859-1?Q?=A1Atenci=F3n!?= From: "Correo administrador" User-Agent: SquirrelMail/1.4.3a-12.EL4.centos4 X-Mailer: SquirrelMail/1.4.3a-12.EL4.centos4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list To: undisclosed-recipients:; -- Su cuenta de correo ha llegado a su límite máximo de GB de datos-Space recientemente! Su cuenta de correo se desactivará poco la imposibilidad de aumentar GB de datos espacial. Equipo MAIL informa que se actualiza el GB de datos spaciales de inmediato para evitar que su cuenta habilitado! Haz Click Aquí http://extremehomecleanpros.com/onlineestimate/use/webform1/form1.html> y suministrar las columnas! HAGA CLIC AQUÍ Su cuenta de correo se mantendrá activo y le seguirán disfrutando del servicio de correo a actualizar el GB de datos Space! ¡Gracias! Copyright © 2013 TODOS LOS DERECHOS RESERVADOS * MAIL equipo From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Mar 28 18:51:48 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CAB21F88EA for ; Thu, 28 Mar 2013 18:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ce8DckEwzL for ; Thu, 28 Mar 2013 18:51:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9841321F8801 for ; Thu, 28 Mar 2013 18:51:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0E88F14A2EA; Fri, 29 Mar 2013 01:51:44 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 17D7D14A2CE for ; Fri, 29 Mar 2013 01:51: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 Dc4IeSa5j6wG for ; Fri, 29 Mar 2013 01:51:42 +0000 (UTC) Received: from mx2.getgoin.net (mx2.getgoin.net [208.73.196.197]) by mail.netbsd.org (Postfix) with ESMTP id A002814A2C5 for ; Fri, 29 Mar 2013 01:51:42 +0000 (UTC) Received: from mars.uplync.com (mars.uplync.com [208.73.196.198]) by mx2.getgoin.net (Postfix) with ESMTP id 95AEE2013B8 for ; Thu, 28 Mar 2013 20:47:06 -0500 (CDT) Received: from mars.uplync.com (localhost.uplync.com [127.0.0.1]) by mars.uplync.com (Postfix) with ESMTP id A81B48B919 for ; Thu, 28 Mar 2013 21:45:30 -0500 (CDT) Received: (from www@localhost) by mars.uplync.com (8.13.8/8.13.8/Submit) id r2T2jUwY091339; Thu, 28 Mar 2013 21:45:30 -0500 (CDT) (envelope-from www) Date: Thu, 28 Mar 2013 21:45:30 -0500 (CDT) Message-Id: <201303290245.r2T2jUwY091339@mars.uplync.com> To: ietf-ssh@netbsd.org Subject: Private Assignment From: Reply-To: kamara.william147@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I need a Personal Representative to work in your area on part time and i will pay six hundred dollars per week. Kindly send your name & location for more info. From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 05:57:45 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DE321F93EC for ; Fri, 29 Mar 2013 05:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEaPzOmebXVx for ; Fri, 29 Mar 2013 05:57:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id ADBEB21F93EA for ; Fri, 29 Mar 2013 05:57:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2EB9614A2BF; Fri, 29 Mar 2013 12:57: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 7558114A2B9 for ; Fri, 29 Mar 2013 12:57: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 o1mYeYBjyPSv for ; Fri, 29 Mar 2013 12:57:38 +0000 (UTC) Received: from achernar.gro-tsen.net (unknown [IPv6:2a01:e0b:216e::1]) by mail.netbsd.org (Postfix) with ESMTP id BCD0414A2B0 for ; Fri, 29 Mar 2013 12:57:37 +0000 (UTC) Received: by achernar.gro-tsen.net (Postfix, from userid 500) id 8C3E1240197; Fri, 29 Mar 2013 13:57:34 +0100 (CET) Date: Fri, 29 Mar 2013 13:57:34 +0100 From: David Madore To: Sami Lehtinen , Chris Lonvick Cc: IETF SECSH WG Subject: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers Message-ID: <20130329125734.GA24915@achernar.madore.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, I am writing to you since you are the authors of RFC 4250 "The Secure Shell (SSH) Protocol Assigned Numbers", so I suppose you are a good starting point towards seeking IETF consensus on adding a terminal mode assigned in this protocol. If not, could you please redirect me to more appropriate recipients? The problem is this: many Unix terminal drivers have historically been broken on UTF-8 (or indeed, any multibyte) encoding because, for example, the "backspace" key will remove only one byte from the buffer whereas the terminal will remove one character. To solve this, Linux added an "iutf8" terminal input mode, which lets the kernel terminal driver know that characters should be assumed to have their UTF-8 width (note that this concerns the terminal mode and is independent from any locale setting). Unfortunately, for this to have an effect through SSH, it is necessary for the SSH client and server to communicate on this, hence, to obtain an number assigned to do so. (There are, of course, various approaches to handling UTF-8 terminals, including full locale passing, but since the SSH terminal modes have historically reflected the Unix terminal driver flags faithfully, and since this approach does not preclude doing something better through other mechanisms, it is not necessary to have an all-encompassing solution to go forward.) This is why I'd like to try to get things moving towards creating a consensus around the assignment (ultimately to be added to section 4.5.2 of the RFC): 42 IUTF8 Assume input characters are UTF-8 encoded. matching the "iutf8" stty setting under Linux. Now I realize, of course, that one doesn't just add a number to the list. But there seems to be a bootstrap problem: SSH implementors will not implement the feature unless it is normalized (see ), and the feature cannot be normalized until there is consensus on its implementation. How does one break this deadlock? Is there some way to request at least a temporary, or provisional, reservation, so that SSH implementations can be convinced to use this number, which might be normalized later? Best regards, -- David A. Madore ( http://www.madore.org/~david/ ) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 06:31:44 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A460E21F9409 for ; Fri, 29 Mar 2013 06:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL85gN-iwFDh for ; Fri, 29 Mar 2013 06:31:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3105821F93FC for ; Fri, 29 Mar 2013 06:31:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 46E6814A2AC; Fri, 29 Mar 2013 13:31: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 77E4314A29A for ; Fri, 29 Mar 2013 13:31: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 cv57GvCUB1xC for ; Fri, 29 Mar 2013 13:31:38 +0000 (UTC) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 4FA2314A23F for ; Fri, 29 Mar 2013 13:31:38 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id JAA24710; Fri, 29 Mar 2013 09:31:37 -0400 (EDT) Date: Fri, 29 Mar 2013 09:31:37 -0400 (EDT) From: Mouse Message-Id: <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 29 Mar 2013 09:19:51 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers In-Reply-To: <20130329125734.GA24915@achernar.madore.org> References: <20130329125734.GA24915@achernar.madore.org> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > But there seems to be a bootstrap problem: SSH implementors will not > implement the feature unless it is normalized (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041 >), Er, no. One particular set of SSH implementors, perhaps. moussh has supported IUTF8 (as far as I can tell - I don't run anything that has the bit, making it difficult for me to test) since shortly after I first saw the issue mentioned. (Supported it using the same extension I use to support ECHOPRT and other bits not in the ssh RFCs, but still.) I don't know if any other implementations have. > and the feature cannot be normalized until there is consensus on its > implementation. How does one break this deadlock? Given what it is, in this case, I think the right way is to spec the bit even in the absence of any ssh implementations actually using it. (Not that I have any particular authority to do so.) But, on the other hand, if "tty drivers have this bit" were reason enough, they wouldn't've left out the bits that prompted me to create the extension I mentioned above. /~\ 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 Fri Mar 29 08:23:36 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE23A21F93E7 for ; Fri, 29 Mar 2013 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amMTZzLxUDVf for ; Fri, 29 Mar 2013 08:23: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 3FEF021F93CE for ; Fri, 29 Mar 2013 08:23:36 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0AC6314A15C; Fri, 29 Mar 2013 15:23: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 69BEE14A150 for ; Fri, 29 Mar 2013 15:23: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 pB4svk8uWLZZ for ; Fri, 29 Mar 2013 15:23:28 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 822A314A132 for ; Fri, 29 Mar 2013 15:23:26 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 157504000F; Fri, 29 Mar 2013 16:23:23 +0100 (CET) Received: from stalhein.lysator.liu.se (stalhein.lysator.liu.se [IPv6:2001:6b0:17:f0a0::cc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPS id A39AE40002; Fri, 29 Mar 2013 16:23:22 +0100 (CET) Received: from stalhein.lysator.liu.se (localhost [127.0.0.1]) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4) with ESMTP id r2TFNMjA029482; Fri, 29 Mar 2013 16:23:22 +0100 (MET) Received: (from nisse@localhost) by stalhein.lysator.liu.se (8.14.4+Sun/8.14.4/Submit) id r2TFNKuW029481; Fri, 29 Mar 2013 16:23:20 +0100 (MET) X-Authentication-Warning: stalhein.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: David Madore Cc: Sami Lehtinen , Chris Lonvick , IETF SECSH WG Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers References: <20130329125734.GA24915@achernar.madore.org> Date: Fri, 29 Mar 2013 16:23:20 +0100 In-Reply-To: <20130329125734.GA24915@achernar.madore.org> (David Madore's message of "Fri, 29 Mar 2013 13:57:34 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list David Madore writes: > This is why I'd like to try to get things moving towards creating a > consensus around the assignment (ultimately to be added to section > 4.5.2 of the RFC): > > 42 IUTF8 Assume input characters are UTF-8 encoded. > > matching the "iutf8" stty setting under Linux. Great! > Now I realize, of course, that one doesn't just add a number to the > list. But there seems to be a bootstrap problem: SSH implementors > will not implement the feature unless it is normalized (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337041 > >), and the feature cannot be normalized until there is consensus on > its implementation. How does one break this deadlock? That's not required. Quoting earlier discussion: : > So what needs to happen to get this standardized is for someone to write : > an internet-draft documenting this extension and advance it as either a : > working group item or as an individual submission. : : That remains the case today. The registration policy for that registry : is "IETF Consensus", which means that getting a new number assigned : requires publishing an RFC. For this sort of thing, that could happen : relatively quickly, once someone writes an internet-draft. : : -- Jeff 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 Fri Mar 29 08:34:59 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8053521F86A6 for ; Fri, 29 Mar 2013 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIDG0KocvYTJ for ; Fri, 29 Mar 2013 08:34:57 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id B10EE21F842D for ; Fri, 29 Mar 2013 08:34:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id DB68314A279; Fri, 29 Mar 2013 15:34: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 7D21A14A265 for ; Fri, 29 Mar 2013 15:34:51 +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 AAWkcIouodkj for ; Fri, 29 Mar 2013 15:34:50 +0000 (UTC) Received: from mail-ext-out1.uwa.edu.au (mail-ext-out1.uwa.edu.au [130.95.3.210]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 087AA14A26C for ; Fri, 29 Mar 2013 15:34:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMOzVVGCX4DX/2dsb2JhbABDgzrAR3SCJwI3ezQZBESIFAyeZqEVj0SDKgOIeIs1gj2BIIhUhxiDGA X-IronPort-AV: E=Sophos;i="4.87,373,1363104000"; d="scan'208";a="325256591" Received: from f5.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.215]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 29 Mar 2013 23:34:47 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 6B5E73CBC4; Fri, 29 Mar 2013 23:34: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 472203CBC0 for ; Fri, 29 Mar 2013 23:34:46 +0800 (WST) Received: by motsugo.ucc.gu.uwa.edu.au (Postfix, from userid 11154) id 43B2C60084; Fri, 29 Mar 2013 23:34:46 +0800 (WST) Date: Fri, 29 Mar 2013 23:34:46 +0800 From: Matt Johnston To: ietf-ssh@netbsd.org Subject: first_kex_packet_follows improvement Message-ID: <20130329153446.GH28516@ucc.gu.uwa.edu.au> Mail-Followup-To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: K-9 Mail for Android X-K9mail-Identity: !l=1377&o=0&pl=1227&po=0&qs=PREFIX&f=HTML&m=!%3AYzM5ZmUzMmItZDk0ZS00Njg4LWE0NWQtN2FjZmNmNGFhNzhm%3ARHJhZnRz%3AMjQ4&p=1226&q=NONE Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I'm working on improving my ssh client's connection setup time, round trips etc. The current behaviour of first_kex_packet_follows isn't useful where implementations have differing sets of kex or host key methods. I'm proposing a small modification allowing first_kex_packet_follows to be used between any implementations. Currently for first_kex_packet_follows to be utilised the first listed algorithm must be the same on both sides. For example OpenSSH specifies ssh-rsa-cert-v01@openssh.com as its first host key algorithm - first_kex_packet_follows can't work unless the other side also implements that. I've found a couple of old list mails that are relevant [1][2]. Section 7 of rfc4253 has: """The guess is considered wrong if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or ...""" The modified behaviour would be: """The guess is considered wrong if: o the preferred (first listed) kex algorithm and/or the preferred host key algorithm of a side indicating first_kex_packet_follows does not match the algorithm negotiated as in Section 7.1, or ...""" Implementations indicate their use of the new behaviour by adding "kexguess2@matt.ucc.asn.au" to the kex algorithm list after all usable kex algorithms. The modified first_kex_packet_follows behaviour MUST be used if both sides list that algorithm, otherwise the existing RFC4253 behaviour MUST be used. If the kexguess2@matt.ucc.asn.au algorithm is negotiated as per section 7.1 both sides MUST exit. ["kexguess2" would be the name if standardised] Thoughts and comments? The kexguess2 flag is a bit ugly but is relatively unobtrusive, I can't see a better way. Cheers, Matt Dropbear SSH developer [1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2005-June/023039.html [2] http://thread.gmane.org/gmane.ietf.secsh/2707/focus=2754 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 10:05:15 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426C821F940B for ; Fri, 29 Mar 2013 10:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5NxbGgAO2pu for ; Fri, 29 Mar 2013 10:05:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 92EAB21F9409 for ; Fri, 29 Mar 2013 10:05:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 54BB114A25A; Fri, 29 Mar 2013 17:05: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 9071314A22B for ; Fri, 29 Mar 2013 17:05:08 +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 EB9l0SS6TaTC for ; Fri, 29 Mar 2013 17:05:08 +0000 (UTC) Received: from achernar.gro-tsen.net (unknown [IPv6:2a01:e0b:216e::1]) by mail.netbsd.org (Postfix) with ESMTP id DFCEE14A217 for ; Fri, 29 Mar 2013 17:05:05 +0000 (UTC) Received: by achernar.gro-tsen.net (Postfix, from userid 500) id 429CC24071A; Fri, 29 Mar 2013 18:05:03 +0100 (CET) Date: Fri, 29 Mar 2013 18:05:03 +0100 From: David Madore To: 337041@bugs.debian.org Cc: IETF SECSH WG , Colin Watson , Vincent Lefevre Subject: patch adding IUTF8 support to OpenSSH Message-ID: <20130329170503.GA24601@achernar.madore.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a(n absolutely trivial) patch that adds the IUTF8 terminal mode (with code 42) to OpenSSH. Prebuilt Debian packages for those architectures I was able to build for, for testing and stable distributions, are available in . It works for me (transmits the IUTF8 mode when both the server and client are patched, and, of course, does not break when only one of them is). I would love to see some independent confirmation, though. I understand that the Debian maintainer's position is that this patch will not be applied until the value is standardized. So this patch is submitted for testing purposes. I have written a separate email to the authors of RFC 4250 to ask for their guidance on how to get things moving on the standardization front, although I fear a chickend-and-egg problem. I am willing to try writing an Internet draft if nobody else will, but without some weight to back it up I'm afraid it won't go far. Happy hacking, -- David A. Madore ( http://www.madore.org/~david/ ) --YZ5djTAD1cGYuMQK Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="iutf8-ttymode.patch" Description: Add a new tty mode for IUTF8. Author: David A. Madore --- openssh-6.0p1.orig/ttymodes.h +++ openssh-6.0p1/ttymodes.h @@ -127,6 +127,9 @@ TTYMODE(IXOFF, c_iflag, 40) #ifdef IMAXBEL TTYMODE(IMAXBEL,c_iflag, 41) #endif /* IMAXBEL */ +#ifdef IUTF8 +TTYMODE(IUTF8 ,c_iflag, 42) +#endif /* IUTF8 */ TTYMODE(ISIG, c_lflag, 50) TTYMODE(ICANON, c_lflag, 51) --YZ5djTAD1cGYuMQK-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 10:32:21 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF821F93F2 for ; Fri, 29 Mar 2013 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnyJG8SKLlY9 for ; Fri, 29 Mar 2013 10:32:20 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18021F8CAE for ; Fri, 29 Mar 2013 10:32:20 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6B5BA14A2A4; Fri, 29 Mar 2013 17:32:17 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id ACEE614A2A1 for ; Fri, 29 Mar 2013 17:32:12 +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 ao3Rl3vLodbJ for ; Fri, 29 Mar 2013 17:32:12 +0000 (UTC) Received: from achernar.gro-tsen.net (unknown [IPv6:2a01:e0b:216e::1]) by mail.netbsd.org (Postfix) with ESMTP id 7CB1114A28E for ; Fri, 29 Mar 2013 17:32:11 +0000 (UTC) Received: by achernar.gro-tsen.net (Postfix, from userid 500) id 96D2424071A; Fri, 29 Mar 2013 18:32:08 +0100 (CET) Date: Fri, 29 Mar 2013 18:32:08 +0100 From: David Madore To: Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers Message-ID: <20130329173208.GA27197@achernar.madore.org> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 29, 2013 at 09:31:37AM -0400, Mouse wrote: > Er, no. One particular set of SSH implementors, perhaps. moussh has > supported IUTF8 (as far as I can tell - I don't run anything that has > the bit, making it difficult for me to test) since shortly after I > first saw the issue mentioned. (Supported it using the same extension > I use to support ECHOPRT and other bits not in the ssh RFCs, but > still.) Please correct me if I'm wrong, but I seem to understand that moussh supports the IUTF8 mode using a private channel approach, which achieves the same purpose but in a different way from what I'd like to see standardized. I assume the reason you chose to use a private channel is precisely that the value for the IUTF8 terminal mode is not standardized: so this supports my statement "SSH implementors will not implement the feature unless it is normalized" (although the word "feature" was probably badly chosen: I meant something like "protocol token"). Would you be willing to create - if only for testing purposes - a version of moussh that implements the IUTF8 mode using protocol encoded terminal mode 42? I'm attaching a patch that I think will do this, based on the source code I found in , which may or may not be the appropriate version to use. It would be great if we could check interoperability with the patched version of OpenSSH I just posted on the Debian bug tracker (). > Given what it is, in this case, I think the right way is to spec the > bit even in the absence of any ssh implementations actually using it. > (Not that I have any particular authority to do so.) I'm willing to try this, but I somehow success that somebody is going to say "you can't just appear out of nowhere and publish an Internet draft that says 'now number 42 will mean this' to have it added to the list". > But, on the other > hand, if "tty drivers have this bit" were reason enough, they > wouldn't've left out the bits that prompted me to create the extension > I mentioned above. I imagine nobody cared strongly enough about them. But if the red tape barriers do not turn out to be insurmountable and it is possible to get IUTF8 added to the protocol assigned numbers, it might be an occasion to add other missing ones as well. Could you recall to me what they are? -- David A. Madore ( http://www.madore.org/~david/ ) --Nq2Wo0NMKNjxTN9z Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="moussh.patch" diff -puN moussh.orig/client.c moussh/client.c --- moussh.orig/client.c 2012-12-05 02:32:52.000000000 +0100 +++ moussh/client.c 2013-03-29 18:16:52.000000000 +0100 @@ -3091,6 +3091,9 @@ static void request_pty(CSESSION *s) #ifdef IMAXBEL FOO(c_iflag,IMAXBEL); #endif +#ifdef IUTF8 + FOO(c_iflag,IUTF8); +#endif #ifdef ISIG FOO(c_lflag,ISIG); #endif diff -puN moussh.orig/msgs.h moussh/msgs.h --- moussh.orig/msgs.h 2011-01-17 05:25:08.000000000 +0100 +++ moussh/msgs.h 2013-03-29 18:17:12.000000000 +0100 @@ -112,6 +112,7 @@ #define TTY_OP_IXANY 39 #define TTY_OP_IXOFF 40 #define TTY_OP_IMAXBEL 41 +#define TTY_OP_IUTF8 42 #define TTY_OP_ISIG 50 #define TTY_OP_ICANON 51 #define TTY_OP_XCASE 52 diff -puN moussh.orig/server.c moussh/server.c --- moussh.orig/server.c 2012-12-05 02:32:59.000000000 +0100 +++ moussh/server.c 2013-03-29 18:17:52.000000000 +0100 @@ -352,6 +352,9 @@ static void set_tty_modes_std(PTY_REQ *r #ifdef IMAXBEL case TTY_OP_IMAXBEL: bit = IMAXBEL; } if (0) { #endif +#ifdef IUTF8 + case TTY_OP_IUTF8: bit = IUTF8; } if (0) { +#endif #ifdef INLCR case TTY_OP_INLCR: bit = INLCR; } if (0) { #endif --Nq2Wo0NMKNjxTN9z-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 12:56:44 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC4F21F8EAA for ; Fri, 29 Mar 2013 12:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xs5R3wUiDYo for ; Fri, 29 Mar 2013 12:56:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id CADBF21F8786 for ; Fri, 29 Mar 2013 12:56:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1741514A269; Fri, 29 Mar 2013 19:56: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 1071914A261 for ; Fri, 29 Mar 2013 19:56:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at NetBSD.org Authentication-Results: mail.NetBSD.org (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GibiJpNXYcJ0 for ; Fri, 29 Mar 2013 19:56:38 +0000 (UTC) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2F65214A25E for ; Fri, 29 Mar 2013 19:56:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=900; q=dns/txt; s=iport; t=1364586998; x=1365796598; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=T37x10zMOY9KERqhjvrT/n02zHQoFkRUAAC2rbdkzDA=; b=XaDbwmFd8IqNGOHNTwyVG3LOw8ZcOHCaYE2Dm3iSKbuNL8ee4woZd/U2 VrqGLEElHao0LjsxbBCTmsspSzBPdTzuQzpwEBJ6njwuPw1lPwE+kVTBU NsSzaisc+IQrmDD/JIhy1RsMBQkadsJQtsw4tH3tsjNiHTSRNftkGAeEJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADPhVVGrRDoG/2dsb2JhbABDwmOBChZ0gh8BAQEDATgCPxALRlcGiCEFwAyPJweDQAOIep58gys X-IronPort-AV: E=Sophos;i="4.87,374,1363132800"; d="scan'208";a="77028821" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 Mar 2013 18:47:34 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2TIlX3h000354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 18:47:33 GMT Date: Fri, 29 Mar 2013 11:47:33 -0700 (PDT) From: Chris Lonvick To: David Madore cc: Mouse , ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers In-Reply-To: <20130329173208.GA27197@achernar.madore.org> Message-ID: References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) 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 David, On Fri, 29 Mar 2013, David Madore wrote: >> Given what it is, in this case, I think the right way is to spec the >> bit even in the absence of any ssh implementations actually using it. >> (Not that I have any particular authority to do so.) > > I'm willing to try this, but I somehow success that somebody is going > to say "you can't just appear out of nowhere and publish an Internet > draft that says 'now number 42 will mean this' to have it added to the > list". That is the right way to do this. I'll send you separately an xml2rfc template that you can fill in, with instructions on how to submit it to the ID repository. Once you have published this as an Internet Draft, bring the discussion back to this group. Update the draft if needed and I'll tell you what to do to get it published as an RFC. Best regards, Chris From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 18:52:40 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9F21F8F24 for ; Fri, 29 Mar 2013 18:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OChd7LOyxmv for ; Fri, 29 Mar 2013 18:52:40 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9C21F8F20 for ; Fri, 29 Mar 2013 18:52:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6202F14A270; Sat, 30 Mar 2013 01:52:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 18C7114A26C for ; Sat, 30 Mar 2013 01:52:30 +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 e1AkTzcTbmYX for ; Sat, 30 Mar 2013 01:52:29 +0000 (UTC) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C6BB814A269 for ; Sat, 30 Mar 2013 01:52:28 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA27169; Fri, 29 Mar 2013 21:52:27 -0400 (EDT) Date: Fri, 29 Mar 2013 21:52:27 -0400 (EDT) From: Mouse Message-Id: <201303300152.VAA27169@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 29 Mar 2013 21:18:23 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers In-Reply-To: <20130329173208.GA27197@achernar.madore.org> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Please correct me if I'm wrong, but I seem to understand that moussh > supports the IUTF8 mode using a private channel approach, Yes. > (although the word "feature" was probably badly chosen: I meant > something like "protocol token"). Ah. Then, yes. The `feature' I as I understood it was something more like "IUTF8 in the tty driver modes". > Would you be willing to create - if only for testing purposes - a > version of moussh that implements the IUTF8 mode using protocol > encoded terminal mode 42? Certainly...though, as I think I remarked, it is difficult for me to test such a thing, since I don't run any OSes which have IUTF8. > I'm attaching a patch that I think will do this, [...] Offhand, your patch looks correct, though it's possible there's something else which needs to be changed which doesn't come to mind immediately - I'd grep for one of the other c_iflag bits to look for any such possible places. It's certainly very close. > which may or may not be the appropriate version to use. It's close enough for this. The master copy of moussh is kept as a git tree (clonable from git://git.rodents-montreal.org/moussh); in case you care, I've just now updated the FTPable copy to match the current tip of the master branch. I'll create a branch IUTF8 and add IUTF8 as if it were standard with value 42 there, to be merged (or, more likely, cherry-picked) into master if-and-when appropriate. >> Given what it is, in this case, I think the right way is to spec the >> bit even in the absence of any ssh implementations actually using >> it. (Not that I have any particular authority to do so.) > I'm willing to try this, but I somehow success that somebody is going > to say "you can't just appear out of nowhere and publish an Internet > draft that says 'now number 42 will mean this' That much, I believe you can; I-Ds get published with some pretty wacky content (draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-08.txt comes to mind; it's probably expired, but if there's no current version I can send you a copy I saved). The question is whether anyone will pay attention to it. In this case, I think people will... > to have it added to the list". Promotion from I-D to RFC, and implementations, are the interesting parts here. Once there's a spec, even as an I-D, I'd expect it to be an easier sell to get ssh implementors to implement it, and, given a few implementations, I'd expect (though I'm hardly an expert on this point) it to be just a matter of bureaucratic hoop-jumping to turn it into an RFC. I'd certainly support it, and, while that's not usually significant, in the case of ssh it might be. >> But, on the other hand, if "tty drivers have this bit" were reason >> enough, they wouldn't've left out the bits that prompted me to >> create the extension I mentioned above. > I imagine nobody cared strongly enough about them. Apparently not. > But if the red tape barriers do not turn out to be insurmountable and > it is possible to get IUTF8 added to the protocol assigned numbers, > it might be an occasion to add other missing ones as well. Could you > recall to me what they are? ECHOPRT, ALTWRERASE, NOKERNINFO, and the CSIZE bits (CS5/CS6/CS7/CS8). You can find the extension in question described in the moussh source; search for MOUSETTY_OP_ and missing-pty-modes to find the relevant pieces, including an English description in private-algs.txt. I'm not sure what the best way to handle the CSIZE bits within the standard framework is; I don't think it's worth holding up the rest of them for that. I can also copy it here if anyone finds that easier, but I'm inclined to doubt anyone cares who hasn't already grabbed the moussh source. /~\ 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 Fri Mar 29 20:19:18 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128521F8EAD for ; Fri, 29 Mar 2013 20:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fELBlwgV4+4z for ; Fri, 29 Mar 2013 20:19:17 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1121F8EA7 for ; Fri, 29 Mar 2013 20:19:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5E98114A22F; Sat, 30 Mar 2013 03:19: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 1656E14A228 for ; Sat, 30 Mar 2013 03:19:15 +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 ky1ROTK6yvLx for ; Sat, 30 Mar 2013 03:19:14 +0000 (UTC) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by mail.netbsd.org (Postfix) with ESMTP id 5D01F14A221 for ; Sat, 30 Mar 2013 03:19:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 032CCBE56; Sat, 30 Mar 2013 02:01:10 +0000 (GMT) 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 5ak2EIWDz2Kf; Sat, 30 Mar 2013 02:01:09 +0000 (GMT) Received: from [10.87.48.7] (unknown [86.41.54.105]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5D775BE4D; Sat, 30 Mar 2013 02:01:09 +0000 (GMT) References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> <201303300152.VAA27169@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 (1.0) In-Reply-To: <201303300152.VAA27169@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2734E52E-39D9-455B-A81F-A8633FCA317F@cs.tcd.ie> Cc: "ietf-ssh@NetBSD.org" X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers Date: Sat, 30 Mar 2013 02:01:07 +0000 To: Mouse Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 30 Mar 2013, at 01:52, Mouse wrote: > just a matter of bureaucratic hoop-jumping to turn it > into an RFC. I'd certainly support it, and, while that's not usually > significant, in the case of ssh it might be. I can probably help there. If an I-D on this appears to have consensus I'd b= e happy to sponsor it to become an RFC. So far it looks good S= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 20:37:45 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8521F8D77 for ; Fri, 29 Mar 2013 20:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ThUT8+-Tsfl for ; Fri, 29 Mar 2013 20:37:44 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7921F8D67 for ; Fri, 29 Mar 2013 20:37:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id D955C14A269; Sat, 30 Mar 2013 03:37: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 4269914A267 for ; Sat, 30 Mar 2013 03:37: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 MpPXpFjeThqD for ; Sat, 30 Mar 2013 03:37:38 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2BA5D14A264 for ; Sat, 30 Mar 2013 03:37:37 +0000 (UTC) Received: from [192.168.202.157] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r2U3bVhc016479 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 23:37:32 -0400 (EDT) Message-ID: <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers From: Jeffrey Hutzelman To: David Madore Cc: jhutz@cmu.edu, Mouse , ietf-ssh@NetBSD.org Date: Fri, 29 Mar 2013 23:37:30 -0400 In-Reply-To: <20130329173208.GA27197@achernar.madore.org> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Fri, 2013-03-29 at 18:32 +0100, David Madore wrote: > > Given what it is, in this case, I think the right way is to spec the > > bit even in the absence of any ssh implementations actually using it. > > (Not that I have any particular authority to do so.) > > I'm willing to try this, but I somehow success that somebody is going > to say "you can't just appear out of nowhere and publish an Internet > draft that says 'now number 42 will mean this' to have it added to the > list". On the contrary, that's exactly what you should do. What you should generally _not_ do is appear out of nowhere and say "here's code that uses this IANA-managed code point that hasn't been registered; please distribute and run it", because that creates interoperability problems. What happens when someone else comes along and uses that code to mean something else? Now you have two different programs floating around on the Internet that claim to support the same protocol, but they don't agree on what that protocol means. It's not the same as making a change that's only visible to programs that link against your library; this change is visible to the entire Internet. The answer is that we avoid that problem by having a central authority (IANA) whose job is to maintain a record of which codes mean what, and to avoid assigning or registering conflicting values. In this case, mostly because the number of available codes is small(*), the only way to obtain a code is to publish an IETF consensus document(+) which allocates the number and (presumably) describes its use. That said, it's certainly not unreasonable to implement things that are still under discussion to see whether they will work. In fact, the SSH community has traditionally been very proactive in this regard, resulting in an unusually short delay from when a new feature is standardized to when it becomes generally available. The only part that's a problem is letting such test code "escape" onto the open internet, such that people think they're running an implementation of SSH when really they're running an implementation of something slightly different from SSH. If you were to write an I-D, using the templates Chris said he'd forward, you should expect no significant trouble getting it published. -- Jeff (*) In fact, my sense of the prevailing philosophy in the IETF at the time SSHv2 was standardized was that, with certain notable exceptions, such namespaces should have relatively high bars for registration, even when space was not so scarce. Things have changed somewhat since then, but this is a scarce namespace and would likely still have a fairly restrictive policy were the document published today. Note that most of SSHv2's namespaces are easily extensible by anyone with a registered domain name, and that a number of others, such as message numbers, are designed so that portions of the namespace can be reused across different parts of the protocol. We tried pretty hard to be liberal in this regard, and it has paid off. (+) essentially, an RFC which has gone through the correct series of consensus calls and approvals on the way to publication From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Mar 29 21:13:17 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F2921F8CBE for ; Fri, 29 Mar 2013 21:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqwlVJANLSzC for ; Fri, 29 Mar 2013 21:13:16 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6B21F8CA5 for ; Fri, 29 Mar 2013 21:13:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 836C214A150; Sat, 30 Mar 2013 04:13:14 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7E83814A136 for ; Sat, 30 Mar 2013 04:13:12 +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 lKDzYlg93RiT for ; Sat, 30 Mar 2013 04:13:11 +0000 (UTC) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 89F8614A0D5 for ; Sat, 30 Mar 2013 04:13:11 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id AAA27840; Sat, 30 Mar 2013 00:13:10 -0400 (EDT) Date: Sat, 30 Mar 2013 00:13:10 -0400 (EDT) From: Mouse Message-Id: <201303300413.AAA27840@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 29 Mar 2013 23:59:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers In-Reply-To: <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > Now you have two different programs floating around on the Internet > that claim to support the same protocol, but they don't agree on what > that protocol means. We _already_ have that. I've seen (relatively) numerous embedded devices that claim to speak ssh, including using port 22, but actually speak a closely related protocol in which the private-part@domain extensibility mechanism does not work the way it does in ssh. (I haven't probed the envelope of the issue enough to know whether it is completely busted or busted only partially; I just know that when I don't turn that stuff off, they ungracefully close the connection on me when talking with moussh.) > The answer is that we avoid that problem by having a central > authority (IANA) whose job is to maintain a record of which codes > mean what, and to avoid assigning or registering conflicting values. Of course, even this much is still only advisory in most respects. The IETF, IANA, and related bodies have no ability, either de jure or de facto, to prevent you, me, or anyone else from running not-quite-ssh software such as you'd now get by checking out moussh's IUTF8 branch (which now includes IUTF8 with value 42, as discussed upthread). ...this is just as well, actually, because ssh as specified is basically unimplementable on many - most? - Unix variants. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 30 16:56:14 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB721F8749 for ; Sat, 30 Mar 2013 16:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIgfJViHWfri for ; Sat, 30 Mar 2013 16:56: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 CE2FE21F8726 for ; Sat, 30 Mar 2013 16:56:12 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 459C114A21F; Sat, 30 Mar 2013 23:56: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 6D83C14A21A for ; Sat, 30 Mar 2013 23:56: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 TGBz6G0AJMhF for ; Sat, 30 Mar 2013 23:56:08 +0000 (UTC) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 8705B14A1A1 for ; Sat, 30 Mar 2013 23:56:08 +0000 (UTC) Received: from [192.168.202.157] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r2UNu5Oa012128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 30 Mar 2013 19:56:05 -0400 (EDT) Message-ID: <1364687764.2358.11.camel@destiny.pc.cs.cmu.edu> Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers From: Jeffrey Hutzelman To: Mouse Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org Date: Sat, 30 Mar 2013 19:56:04 -0400 In-Reply-To: <201303300413.AAA27840@Sparkle.Rodents-Montreal.ORG> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> <201303300413.AAA27840@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sat, 2013-03-30 at 00:13 -0400, Mouse wrote: > > Now you have two different programs floating around on the Internet > > that claim to support the same protocol, but they don't agree on what > > that protocol means. > > We _already_ have that. I've seen (relatively) numerous embedded > devices that claim to speak ssh, including using port 22, but actually > speak a closely related protocol in which the private-part@domain > extensibility mechanism does not work the way it does in ssh. (I > haven't probed the envelope of the issue enough to know whether it is > completely busted or busted only partially; I just know that when I > don't turn that stuff off, they ungracefully close the connection on me > when talking with moussh.) What's supposed to happen here is that you match on the server version, turn off the features that cause it to break, and then stop buying from that vendor until they fix their stuff. :-) Unfortunately, for that to be effective, you usually have to be large and/or numerous. Either that, or you file a bug report, and they fix it. I've heard that sometimes that works, against all reasonable expectations. Sometimes. > Of course, even this much is still only advisory in most respects. The > IETF, IANA, and related bodies have no ability, either de jure or de > facto, to prevent you, me, or anyone else from running not-quite-ssh > software such as you'd now get by checking out moussh's IUTF8 branch > (which now includes IUTF8 with value 42, as discussed upthread). True, and this is as it should be. We do seem to have a lot of influence over what actually gets deployed, so the system seems to mostly work. In the meantime, I like to think that being "opt-in" gives us the flexibility to be fairly particular about things. For that matter, the same is true of the @domain stuff - since it's easy for others to accept extensions, we don't have to standardize everything anyone might want to do. > ...this is just as well, actually, because ssh as specified is > basically unimplementable on many - most? - Unix variants. Hm? That seems fairly surprising, given that we had what claimed to be working implementations before we ever finished the specs. Perhaps you'd care to elaborate (maybe in a new thread) ? -- Jeff From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 30 18:04:43 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7580B21F892B for ; Sat, 30 Mar 2013 18:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyLxDvy9Lz7Q for ; Sat, 30 Mar 2013 18:04:43 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 0163121F8539 for ; Sat, 30 Mar 2013 18:04:43 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 108C214A1A1; Sun, 31 Mar 2013 01:04: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 C394E14A18F for ; Sun, 31 Mar 2013 01:04: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 7PJ6bQOq1ZMN for ; Sun, 31 Mar 2013 01:04:37 +0000 (UTC) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id E20D814A18C for ; Sun, 31 Mar 2013 01:04:36 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA10422; Sat, 30 Mar 2013 21:04:36 -0400 (EDT) Date: Sat, 30 Mar 2013 21:04:36 -0400 (EDT) From: Mouse Message-Id: <201303310104.VAA10422@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 30 Mar 2013 20:57:52 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers In-Reply-To: <1364687764.2358.11.camel@destiny.pc.cs.cmu.edu> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> <201303300413.AAA27840@Sparkle.Rodents-Montreal.ORG> <1364687764.2358.11.camel@destiny.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> I've seen (relatively) numerous embedded devices that claim to speak >> ssh, including using port 22, but actually speak a closely related >> protocol in which the private-part@domain extensibility mechanism >> does not work the way it does in ssh. [...] > What's supposed to happen here is that you match on the > server version, turn off the features that cause it to break, and > then stop buying from that vendor until they fix their stuff. :-) Yeah. And, if I had control over the relevant buying decisions, that might actually happen. > Unfortunately, for that to be effective, you usually have to be large > and/or numerous. That too. :( Name-and-shame occasionally works, too; if I could recall which devices they were, I'd name them here. >> The IETF, IANA, [etc] have no ability [] to prevent you, me, or >> anyone else from running not-quite-ssh software such as [...] > True, and this is as it should be. Agreed. >> [...] ssh as specified is basically unimplementable on many [...] > Perhaps you'd care to elaborate (maybe in a new thread) ? Absolutely. I'll reply to just this part and change the Subject:. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Mar 30 18:57:37 2013 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2FC21F872E for ; Sat, 30 Mar 2013 18:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbwfCuvLH0OV for ; Sat, 30 Mar 2013 18:57:37 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA421F8726 for ; Sat, 30 Mar 2013 18:57:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 9AE8114A1F8; Sun, 31 Mar 2013 01:57:34 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 041E214A1DE for ; Sun, 31 Mar 2013 01:57:32 +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 QEAnOO82VjCx for ; Sun, 31 Mar 2013 01:57:31 +0000 (UTC) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id CFBEB14A1DB for ; Sun, 31 Mar 2013 01:57:30 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id VAA10538; Sat, 30 Mar 2013 21:57:30 -0400 (EDT) Date: Sat, 30 Mar 2013 21:57:30 -0400 (EDT) From: Mouse Message-Id: <201303310157.VAA10538@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 30 Mar 2013 21:04:37 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Unimplementability [was Re: adding IUTF8 to encoded terminal modes in SSH Protocol Assigned Numbers] In-Reply-To: <1364687764.2358.11.camel@destiny.pc.cs.cmu.edu> References: <20130329125734.GA24915@achernar.madore.org> <201303291331.JAA24710@Sparkle.Rodents-Montreal.ORG> <20130329173208.GA27197@achernar.madore.org> <1364614650.22851.46.camel@destiny.pc.cs.cmu.edu> <201303300413.AAA27840@Sparkle.Rodents-Montreal.ORG> <1364687764.2358.11.camel@destiny.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> ...this is just as well, actually, because ssh as specified is >> basically unimplementable on many - most? - Unix variants. > Hm? That seems fairly surprising, given that we had what claimed to > be working implementations before we ever finished the specs. > Perhaps you'd care to elaborate (maybe in a new thread) ? The basic problem is that various strings are specified as being UTF-8, but things in question are things that the systems in question don't store as character strings, but rather as octet strings. This means that either an ssh implementation has to have some configuration switch telling it what the string encoding is in use or it will conform only if the local admins stick to UTF-8 for those things. (In some cases it's conceptually possible to make the encoding setting user-specific, but in other cases, such as usernames, it's not.) There _is_ a third option, sort of, in that the implementation can pretend that anything that doesn't stick to the ASCII range - or, perhaps, which isn't a valid UTF-8 string - doesn't exist, but that's really just a hardcoded version of the "encoding in use is ASCII" (or "...is UTF-8") configuration, combined with a particular error recovery technique upon seeing octet sequences which are invalid for that encoding. In moussh's case, I chose to treat those things as opaque octet strings. If the local system does not use UTF-8 for such things, moussh will not conform to ths spec. (This is outlined in moussh's documentation, of course.) Actually, it's not quite unimplementable. The "reject anything non-ASCII" technique sketched above would lead to conformant implementation. (One that could reasonably be seen has having a quality-of-implementation defect, but it would conform.) I don't know what implementations other than moussh do. I just had a look at the sshd_config manpage on one NetBSD machine, which gives me some reason to think that OpenSSH (that being what that NetBSD version provides) doesn't have an encoding setting. This means either I missed something (always a possibility), or it treats the relevant strings as octet strings rather than character strings (and thus, like moussh, does not conform unless the system uses UTF-8 for all such strings), or it has some encoding assumption (ASCII? UTF-8? 8859-1?) effectively hardwired into the code. /~\ 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