From sigler@zedat.fu-berlin.de Tue Mar 31 10:00:37 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19E73A2456 for ; Tue, 31 Mar 2020 10:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rZX7aqJsV5yL for ; Tue, 31 Mar 2020 10:00:34 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1AF3A2457 for ; Tue, 31 Mar 2020 10:00:34 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.93) for curdle@ietf.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from ) id 1jJKFc-002Ie0-U9; Tue, 31 Mar 2020 19:00:32 +0200 Received: from port-92-195-65-238.dynamic.as20676.net ([92.195.65.238] helo=[192.168.1.215]) by inpost2.zedat.fu-berlin.de (Exim 4.93) for curdle@ietf.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (envelope-from ) id 1jJKFc-000XJR-Ix; Tue, 31 Mar 2020 19:00:32 +0200 From: Marian Sigler To: curdle@ietf.org Message-ID: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de> Date: Tue, 31 Mar 2020 19:00:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Original-Sender: sigler@inf.fu-berlin.de X-Originating-IP: 92.195.65.238 Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2020 04:10:56 -0700 Subject: [Curdle] On SSH-XMSS X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 11:06:33 -0000 Hi everyone. I've stumbled upon the SSH-XMSS draft [1], and, after being very astonished about it not mentioning the problems arising from XMSS's statefulness, I found your discussion and I am glad that you decided not to proceed on it. I was wondering if it was possible to add a note to the draft that it has been rejected? Also, NIST has now published the Recommendations about stateful schemes you've been talking about as a draft (already in December, actually) : https://doi.org/10.6028/NIST.SP.800-208-draft Since it hasn't been mentioned here, I thought some of you might appreciate the hint. To summarize: The recommendation explicitly forbids any use of XMSS outside of hardware security modules. Further, it demands that the keys be generated inside the hardware module, and that it never exports private keying material. Marian [1] https://tools.ietf.org/id/draft-mu-curdle-ssh-xmss-00.html From nobody Wed Apr 1 06:38:53 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE703A0F2A for ; Wed, 1 Apr 2020 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 gS2CDSvzVCNh for ; Wed, 1 Apr 2020 06:38:49 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F683A0F2D for ; Wed, 1 Apr 2020 06:38:25 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 031DbU8G001092; Wed, 1 Apr 2020 14:38:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ZLhHUz/xQbUIZEMxhn1iTBPJEkOqT86HPh3W+ExTVVA=; b=N2dSuIjUiteJ0+CuSIxGcHlTjcrK4kLZYVg9MfKUVHUXVQg+mA12u71HQgxbQLMdV0Ae C+3pCQ6004c4NfB8p0SVoBtf1GVsQiDbbdDhBlHOSl64RA8/ifn/FEfpGrVs4ZcE1z2J yhZmUT6pFBSAtRCBcDzrmILAHkd0eCIi/k0PSn5PoTtQ0oSpvvHjwU2Qh+EZsCpXm/M3 lQvOtcPCsH+fVDQxbQpw5E/iU8PwLmyHtb3mou/yFcXWGUjdLI4YYU+o4Ko2aV7JL60K WdgBzziqLKAgcaNVmlw7hB2BZS8LMWfFadT9HOVj2gx4zKBiPqMMTdMNjn0BcSGJfsXY 0g== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 301ygpj2dn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Apr 2020 14:38:24 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 031DW5jD024223; Wed, 1 Apr 2020 09:38:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 3028cxp1kw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Apr 2020 09:38:22 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 08:38:21 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Wed, 1 Apr 2020 08:38:12 -0500 From: "Salz, Rich" To: Marian Sigler , "curdle@ietf.org" Thread-Topic: [Curdle] On SSH-XMSS Thread-Index: AQHWCBY6eaRLOyc9u0W5uiDXleCv36hkVjWA Date: Wed, 1 Apr 2020 13:38:11 +0000 Message-ID: <25993367-F1BF-4E8C-99B1-F1E8171A82D8@akamai.com> References: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de> In-Reply-To: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: text/plain; charset="utf-8" Content-ID: <4E1711A291218E409262FF181E2B41AE@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-01_01:2020-03-31, 2020-03-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=859 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004010123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-01_01:2020-03-31, 2020-03-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 impostorscore=0 suspectscore=0 phishscore=0 priorityscore=1501 mlxlogscore=847 spamscore=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004010123 Archived-At: Subject: Re: [Curdle] On SSH-XMSS X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 13:38:51 -0000 PiAgICBJIHdhcyB3b25kZXJpbmcgaWYgaXQgd2FzIHBvc3NpYmxlIHRvIGFkZCBhIG5vdGUgdG8g dGhlIGRyYWZ0IHRoYXQgaXQNCiAgICBoYXMgYmVlbiByZWplY3RlZD8NCiAgICANCiAgDQpUaGlz IGlzIGdlbmVyYWxseSBub3QgZG9uZS4gIFRoZSBlbWFpbCBhcmNoaXZlIGlzIHRoZSByZWNvcmQg b2YgZGlzY3Vzc2lvbi4NCiANCg0K From nobody Wed Apr 1 07:44:02 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7663A1086 for ; Wed, 1 Apr 2020 07:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JL4yIMtclgIN for ; Wed, 1 Apr 2020 07:43:50 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DD83A106C for ; Wed, 1 Apr 2020 07:43:49 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id x11so26163620otp.6 for ; Wed, 01 Apr 2020 07:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=omOzgof5sM1PwX3OdG6MWMHfV0jHlDMUKyXI5SrBvqM=; b=AUGcNXnjcHjsxm0XaF9XUW+kJwA46j9CjdA5ZUlgW448jVJZlAAcQAGVhGM4C9pbir uc9zoCkEGcfO5UZhEPyQM2fKrfMt/T0Ia3zocyy0gIicv+YdGf9peYfXnIafYbR4dhBC CNUvOA7PQtqEhiEok3B+B2xASmjJOsOi7XjVgetJk+eiy9WIWRzMLw8Mevr9VT+XlXWq W3KNwM9rK9gemaqhOXAhLW95OfHPpFUpGiPsiAPZdBp1aWlyjy1flimbhJHiI/67wzTH QWLyvDbWk1OuA+A49qskFghct3Zz8nyh67BZKecTNJCeZmXBQZxwoIZCGpClQJ0eCyBy T+0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=omOzgof5sM1PwX3OdG6MWMHfV0jHlDMUKyXI5SrBvqM=; b=iorc5edMkKLsZ1uvIWWAbXkGIEp4PMpHcdnUEwi7BrBJxWE1KL/+MuYu43nLOmsBMn 9QAKDy3KIERbHqR+6tSXxfg3e0UkebJCErWStSMe0YSkhaXpVqKdzVEJ0Cbftg6EhCLE Mz+Wz7JYX0uH2Gi3myBN2mhtv3u6rtIWjOj4uZ1CNel029F1JyCe0OyIvj/xSZsFHWm4 ZlDgzmVRevD8u8tnTc5rzT9AoWemo7SCZQsDdRfZ6Mf7ziJvUa4DorUUK2F+2W9Hs4fq J28wr3TwgaLC95fmZh/5ekb0JcwDHeH6PJ1pLe38y1rvQgElGSLfN2AkOm6MKerm0sKh 3R/Q== X-Gm-Message-State: ANhLgQ1cnfYVc7wgg3zj4eHytLBEKsxzng44NYUrNYMc1sORltLo1zLk +Uc3l2bbxhBHXIEsO+1DFNlucRIh87PcgJZRSSwI7JBt X-Google-Smtp-Source: ADFU+vu7lXTc1vZCOwX+xen90r86iuO5uf3hfEoyDcFBZvzzo1DIO+uB7C8Op/0Y9vj4HFLrzb/H6GzKVQy1uQlESvY= X-Received: by 2002:a9d:6744:: with SMTP id w4mr17152244otm.220.1585752227713; Wed, 01 Apr 2020 07:43:47 -0700 (PDT) MIME-Version: 1.0 References: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de> <25993367-F1BF-4E8C-99B1-F1E8171A82D8@akamai.com> In-Reply-To: <25993367-F1BF-4E8C-99B1-F1E8171A82D8@akamai.com> From: denis bider Date: Wed, 1 Apr 2020 09:43:33 -0500 Message-ID: To: "Salz, Rich" Cc: Marian Sigler , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003c14ff05a23bb6bc" Archived-At: Subject: Re: [Curdle] On SSH-XMSS X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 14:43:53 -0000 --0000000000003c14ff05a23bb6bc Content-Type: text/plain; charset="UTF-8" > > I was wondering if it was possible to add a note to the draft that it has been rejected? > This is generally not done. The email archive is the record of discussion. Let this be my contribution to the email record, then, suggesting that updating the draft as Marian suggests is what SHOULD be done. Discoverability is important and policies such as the one you outline reduce it, I estimate, by two orders of magnitude. (For similar reasons, the text of already published RFCs should be updated with errata, rather than attaching them separately. That current practice reduces discoverability, I estimate, by one order of magnitude.) denis On Wed, Apr 1, 2020 at 8:38 AM Salz, Rich wrote: > > I was wondering if it was possible to add a note to the draft that it > has been rejected? > > > This is generally not done. The email archive is the record of discussion. > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --0000000000003c14ff05a23bb6bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > I was wondering if it was possible= to add a note to the draft that it has been rejected?
> This is generally not done.=C2=A0 The email archive is the record of = discussion.

<= span style=3D"font:small/1.5 Arial,Helvetica,sans-serif;text-align:left;col= or:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;= text-decoration:none;word-spacing:0px;display:inline;white-space:normal;fon= t-size-adjust:none;font-stretch:normal;float:none;background-color:rgb(255,= 255,255)">Let this be my contribution to the email record, then, suggesting= that updating the draft as Marian suggests is what SHOULD be done.<= /div>

Discoverability is im= portant and policies such as the one you outline reduce it, I estimate, by = two orders of magnitude.

= (For similar reasons, the text of already published RFCs should be updated = with errata, rather than attaching them separately. That current practice r= educes discoverability, I estimate, by one order of magnitude.)
<= br>
denis


On We= d, Apr 1, 2020 at 8:38 AM Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 I was wondering if it was possible to add = a note to the draft that it
=C2=A0 =C2=A0 has been rejected?


This is generally not done.=C2=A0 The email archive is the record of discus= sion.


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--0000000000003c14ff05a23bb6bc-- From nobody Wed Apr 1 21:27:02 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7E13A0BED for ; Wed, 1 Apr 2020 21:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 e7o6OZvDK6cq for ; Wed, 1 Apr 2020 21:26:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74873A0BD9 for ; Wed, 1 Apr 2020 21:26:57 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0324QoK2008973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Apr 2020 00:26:52 -0400 Date: Wed, 1 Apr 2020 21:26:50 -0700 From: Benjamin Kaduk To: denis bider Cc: "Salz, Rich" , Marian Sigler , "curdle@ietf.org" Message-ID: <20200402042650.GM50174@kduck.mit.edu> References: <62670578-138e-c87f-5f2f-32b50c1c506d@inf.fu-berlin.de> <25993367-F1BF-4E8C-99B1-F1E8171A82D8@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Curdle] On SSH-XMSS X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 04:27:01 -0000 On Wed, Apr 01, 2020 at 09:43:33AM -0500, denis bider wrote: > > > I was wondering if it was possible to add a note to the draft that it > has been rejected? > > This is generally not done. The email archive is the record of > discussion. > > Let this be my contribution to the email record, then, suggesting that > updating the draft as Marian suggests is what SHOULD be done. There's nothing preventing the WG chairs from having a document editor (not necessarily the current one) upload a final revision with a "tombstone" indicating it's dead and why. The IESG discussed this general topic at one point but it's not really the sort of thing that should get mandated, though having it as an option in the toolbox is useful. > Discoverability is important and policies such as the one you outline > reduce it, I estimate, by two orders of magnitude. > > (For similar reasons, the text of already published RFCs should be updated > with errata, rather than attaching them separately. That current practice > reduces discoverability, I estimate, by one order of magnitude.) In the past year a new mechanism was introduced that shows the results of applying the (verified) errata on top of the document itself, e.g., at https://www.rfc-editor.org/rfc/inline-errata/rfc5280.html . There's a link from the RFC Editor's document-info page next to the link for the "regular" HTMLized version. -Ben From nobody Sun Apr 26 05:03:37 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32D23A0B49 for ; Sun, 26 Apr 2020 05:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 m9dbw8hLXm-p for ; Sun, 26 Apr 2020 05:03:33 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C153A3A0B40 for ; Sun, 26 Apr 2020 05:03:33 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id b13so21190579oti.3 for ; Sun, 26 Apr 2020 05:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1Re1bV2GT3AH6RcRK/BkWHD0ciXq6oLYf5skLiVNKZA=; b=mnT3KwKcx++NFu02ciENB3OPvDwJyCas2C45AK8CJ2WQQa/4Cv3KsfRzzI/adgAVBr iehW4ZNN4379Phb7uj0hzd6QKXtkJz+vpRo81zVZspxixniYzwDJulkwRWv2gVsccEd1 A6LWY7K6V18QXUaDJEpfgUMl7N/1UlzYTEw6mIznTB8ypZqfzzkE3VYMStCKzH7pn9R5 4TII5JUunPkAA2gxokvgsA7oTeuWFB7zHhhpaD3jPCGsGVUnEEHm7LqWmxGxitHet2zj mUUl6dB2bUiWDySGBsKepsyMY9UV8V4WxrzXh1/s9bhIhihfh6MOr/8GkbN1+SwxvQNU K7cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1Re1bV2GT3AH6RcRK/BkWHD0ciXq6oLYf5skLiVNKZA=; b=kLPUg0nCr2wyLyrRnUw7XuOHfZcCc4WjdiRDB6z+4/kH/Ik9t0ykchD0739ow7Digz ueO1ymwC/yDxYc423d8f4vbqRNECpBJPwVJWauCuOfr1fiWA/qRMQMxQZNPEzo16Ax45 znW1pgchNzuh14dgcVkNV8LXa0QBac1r9X0dm2+tyDSwyPdK9vP3tCIHgxsFUu+C6nZs AJ4wrxKLczo+p/iH3YvM0Qfm7dwCmtcR+u5Suzqtago5ahrE0lPX3HwxSRXF6q4NergW BwoGfNJpk9j6ll2dY7ulQJezbpSSeEwCztbgfIzXCbusWtZnSChHjTQvT4Q4FkDVmHA1 RCLA== X-Gm-Message-State: AGi0PuaPQtxjP47EqiBEmI/td58pO73v94njt8PXOYCsHPovrnnXOICh iIw9melcJz4QPyxsSmJEFVDeFCudBGsfyZ3nVBMjrhh7U/Q= X-Google-Smtp-Source: APiQypL2IkXkQSM3AEpq5dKszyTBMZuVwDnxWlL9d1FeLTiQxS1KtBczxB4a8k17/brUxNdyktNbgNzHp9UX7+agMKM= X-Received: by 2002:a9d:874:: with SMTP id 107mr14758620oty.220.1587902612750; Sun, 26 Apr 2020 05:03:32 -0700 (PDT) MIME-Version: 1.0 From: denis bider Date: Sun, 26 Apr 2020 07:03:21 -0500 Message-ID: To: curdle , ietf-ssh@netbsd.org, Damien Miller Content-Type: multipart/alternative; boundary="0000000000002bc59305a43063f4" Archived-At: Subject: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 12:03:36 -0000 --0000000000002bc59305a43063f4 Content-Type: text/plain; charset="UTF-8" Hey all: it has come to my attention that at least one SSH server implementation (a) advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) disconnects on actual receipt of an EXT_INFO message from the client. This happens when we define a general mechanism, but then the most widely used implementations only use certain aspects of it. Lots of implementations now support EXT_INFO sent by the server because it's needed for RSA-SHA2 signatures, but only a handful implementations send EXT_INFO by the client. Bitvise SSH Client sends EXT_INFO if the server supports it. It's free to use or test with - but it runs on Windows and lots of people don't want to test with that. It's possible that your implementation has no need for any of the extensions that would appear in EXT_INFO from the client. However, if you wish for this extensibility to be available in the future, then if your client supports EXT_INFO, I would strongly suggest that it sends it. If you want to send a client-side EXT_INFO that takes minimal effort, I suggest: 1. Ensure that your SSH client can correctly handle SSH_MSG_GLOBAL_REQUEST received at any point. Your client should not disconnect when it receives this message, or act like it received a channel open failure if it receives a global request when it's waiting for a channel open confirmation. These are the two most common error modes relating to global requests. 2. Once you have ensured the above, if the server supports EXT_INFO, send a client-side EXT_INFO implementing the extension "global-requests-ok" as defined in this draft: https://tools.ietf.org/html/draft-ssh-global-requests-ok-00 This tells the server that your client properly implements global requests so that the server can use them for things like active keep-alives. Implementing this would take minimal effort and would help ensure that client-side EXT_INFO remains an available extension mechanism 10 years down the road for SSH. denis --0000000000002bc59305a43063f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all:

it= has come to my attention that at least one SSH server implementation (a) a= dvertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) disc= onnects on actual receipt of an EXT_INFO message from the client.

This happens when we define a general mechanism, but then t= he most widely used implementations only use certain aspects of it. Lots of= implementations now support EXT_INFO sent by the server because it's n= eeded for RSA-SHA2 signatures, but only a handful implementations send EXT_= INFO by the client.

Bitvise SSH Client sends EXT_I= NFO if the server supports it. It's free to use or test with - but it r= uns on Windows and lots of people don't want to test with that.

It's possible that your implementation has no need fo= r any of the extensions that would appear in EXT_INFO from the client. Howe= ver, if you wish for this extensibility to be available in the future, then= if your client supports EXT_INFO, I would strongly suggest that it sends i= t.

If you want to send a client-side EXT_INFO that= takes minimal effort, I suggest:

1. Ensure that y= our SSH client can correctly handle SSH_MSG_GLOBAL_REQUEST received at any = point. Your client should not disconnect when it receives this message, or = act like it received a channel open failure if it receives a global request= when it's waiting for a channel open confirmation. These are the two m= ost common error modes relating to global requests.

2. Once you have ensured the above, if the server supports EXT_INFO, send= a client-side EXT_INFO implementing the extension "global-requests-ok= " as defined in this draft:

https://tools.ietf.o= rg/html/draft-ssh-global-requests-ok-00

This tells the server th= at your client properly implements global requests so that the server can u= se them for things like active keep-alives.

Implem= enting this would take minimal effort and would help ensure that client-sid= e EXT_INFO remains an available extension mechanism 10 years down the road = for SSH.

denis
--0000000000002bc59305a43063f4-- From nobody Sun Apr 26 10:34:05 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779603A0AE6 for ; Sun, 26 Apr 2020 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net 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 3VZeAaOmnc04 for ; Sun, 26 Apr 2020 10:33:59 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370603A0AE4 for ; Sun, 26 Apr 2020 10:33:59 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id fu13so5723501pjb.5 for ; Sun, 26 Apr 2020 10:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2Ohs05WwCVNYnsiYcN/mU+OJq+MHLEM3WQ0vae+vb84=; b=VKmKxHpV8PYfD0iwO6zqTRCBdqTl0AtXAMrJd/u0G6IB5cZjXeUvxhT876qiDcUsz5 NcuOvTbObmnTM7Sc5cYXDF43DI9rildngjiDTLXzqgDAabetfsyjf8EwYJkvQRiolili EdhZUBp1JyYDAHsmM5zW91STB2XKqxmsW2vVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2Ohs05WwCVNYnsiYcN/mU+OJq+MHLEM3WQ0vae+vb84=; b=K/+rllx/3QQ/Getvmpm3DhrBuyp/toRAQGdKEXk01g2zItIyC1d87J1YUBptxzWOXS q5QvGmHnQrW/etCOYM/Tr0UVAJK43iUSzqthdNKGy9+gOJ6Rs72oiAB1S+thscgHu2bD cRKlNxSVhXRKHklNIAj0Ra6OWGSWc6GqAyPfXoFynmMmMhBlHMCSf+2wcV0MsarJvdPU 1nhVGzTTJ0YFSNlEm4e2if8mkzXKDzWGxFOsq4y+EJcZmU3IP99RM4lpxj/MThiS2w/y gCEpgn4MmXNyvemmSfMdP+/ghkilUb8BVoie9SPtBxwfP5PNMUyMthO0ddMiOBXVJ1wz zX+w== X-Gm-Message-State: AGi0PubZ/Pq2ptJ6tlIqkNzCAj590TH2ynD7vhemUSfdOlPRGV2cFRds Z/prJPH3vnrEb0mKw///An3jNw== X-Google-Smtp-Source: APiQypKzf/2EEVK2o6yppfs15CgYvsdNR0Mh/lbfGLX8BYtRCk4PuytAVYFX5CQ3W1Jfi+ESDQrD6w== X-Received: by 2002:a17:902:b78b:: with SMTP id e11mr19161271pls.311.1587922438294; Sun, 26 Apr 2020 10:33:58 -0700 (PDT) Received: from connect.timeheart.net.0.4.a.f.8.1.4.2.0.3.3.0.6.2.ip6.arpa ([2603:3024:18fa:4000::2]) by smtp.gmail.com with ESMTPSA id c59sm9799197pje.10.2020.04.26.10.33.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2020 10:33:57 -0700 (PDT) From: Ron Frederick Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B51794CF-B5F1-47CF-BDA8-2092A3C6CA71" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 26 Apr 2020 10:33:56 -0700 In-Reply-To: Cc: curdle , ietf-ssh@netbsd.org, Damien Miller To: denis bider References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 17:34:03 -0000 --Apple-Mail=_B51794CF-B5F1-47CF-BDA8-2092A3C6CA71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, On Apr 26, 2020, at 5:03 AM, denis bider = wrote: > it has come to my attention that at least one SSH server = implementation (a) advertises support for SSH_MSG_EXT_INFO as defined in = RFC 8308, and (b) disconnects on actual receipt of an EXT_INFO message = from the client. >=20 > This happens when we define a general mechanism, but then the most = widely used implementations only use certain aspects of it. Lots of = implementations now support EXT_INFO sent by the server because it's = needed for RSA-SHA2 signatures, but only a handful implementations send = EXT_INFO by the client. >=20 > Bitvise SSH Client sends EXT_INFO if the server supports it. It's free = to use or test with - but it runs on Windows and lots of people don't = want to test with that. >=20 > It's possible that your implementation has no need for any of the = extensions that would appear in EXT_INFO from the client. However, if = you wish for this extensibility to be available in the future, then if = your client supports EXT_INFO, I would strongly suggest that it sends = it. >=20 > If you want to send a client-side EXT_INFO that takes minimal effort, = I suggest: >=20 > 1. Ensure that your SSH client can correctly handle = SSH_MSG_GLOBAL_REQUEST received at any point. Your client should not = disconnect when it receives this message, or act like it received a = channel open failure if it receives a global request when it's waiting = for a channel open confirmation. These are the two most common error = modes relating to global requests. >=20 > 2. Once you have ensured the above, if the server supports EXT_INFO, = send a client-side EXT_INFO implementing the extension = "global-requests-ok" as defined in this draft: >=20 > https://tools.ietf.org/html/draft-ssh-global-requests-ok-00 = >=20 > This tells the server that your client properly implements global = requests so that the server can use them for things like active = keep-alives. >=20 > Implementing this would take minimal effort and would help ensure that = client-side EXT_INFO remains an available extension mechanism 10 years = down the road for SSH. I=E2=80=99ve made this change in the AsyncSSH =E2=80=9Cdevelop=E2=80=9D = branch as commit https://github.com/ronf/asyncssh/commit/b87291d = , and will roll this = into the next release. Most of the support was already in place as I = already had common code for generating and parsing EXT_INFO on both the = client and server. The changes are as follows: - AsyncSSH now advertises that it will accept EXT_INFO from clients = when acting as a server - AsyncSSH will send the global-requests-ok extension when acting as = a client and talking to a server that supports EXT_INFO from clients Since AsyncSSH doesn=E2=80=99t actually have any heuristics around = disabling the use of global requests based on client software/version, = it doesn=E2=80=99t actually do anything right now when it receives the = =E2=80=98global-requests-ok=E2=80=99 extension. However, I confirmed it = successfully parses received extensions, so it should be easy to process = future extensions from the client when this is needed. I also specifically tested this against the Bitvise server (thanks for = making that available for free for non-commercial use!), and it seems to = work well. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_B51794CF-B5F1-47CF-BDA8-2092A3C6CA71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

On Apr 26, 2020, at = 5:03 AM, denis bider <denisbider.ietf@gmail.com> wrote:
it has come to my = attention that at least one SSH server implementation (a) advertises = support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) disconnects = on actual receipt of an EXT_INFO message from the client.

This = happens when we define a general mechanism, but then the most widely = used implementations only use certain aspects of it. Lots of = implementations now support EXT_INFO sent by the server because it's = needed for RSA-SHA2 signatures, but only a handful implementations send = EXT_INFO by the client.

Bitvise SSH Client sends EXT_INFO if the server supports it. = It's free to use or test with - but it runs on Windows and lots of = people don't want to test with that.

It's possible that your implementation = has no need for any of the extensions that would appear in EXT_INFO from = the client. However, if you wish for this extensibility to be available = in the future, then if your client supports EXT_INFO, I would strongly = suggest that it sends it.

If you want to send a client-side EXT_INFO that takes minimal = effort, I suggest:

1. Ensure that your SSH client can correctly handle = SSH_MSG_GLOBAL_REQUEST received at any point. Your client should not = disconnect when it receives this message, or act like it received a = channel open failure if it receives a global request when it's waiting = for a channel open confirmation. These are the two most common error = modes relating to global requests.

2. Once you have ensured the above, if = the server supports EXT_INFO, send a client-side EXT_INFO implementing = the extension "global-requests-ok" as defined in this draft:

https://tools.ietf.org/html/draft-ssh-global-requests-ok-00=

This tells the server that your client = properly implements global requests so that the server can use them for = things like active keep-alives.

Implementing this would take minimal = effort and would help ensure that client-side EXT_INFO remains an = available extension mechanism 10 years down the road for = SSH.

I=E2=80=99ve made this change in the AsyncSSH = =E2=80=9Cdevelop=E2=80=9D branch as commit https://github.com/ronf/asyncssh/commit/b87291d, and will = roll this into the next release. Most of the support was already in = place as I already had common code for generating and parsing EXT_INFO = on both the client and server. The changes are as follows:

    - AsyncSSH = now advertises that it will accept EXT_INFO from clients when acting as = a server

  =   - AsyncSSH will send the global-requests-ok extension when acting = as a client and talking to a server that supports EXT_INFO from = clients

Since = AsyncSSH doesn=E2=80=99t actually have any heuristics around disabling = the use of global requests based on client software/version, it = doesn=E2=80=99t actually do anything right now when it receives the = =E2=80=98global-requests-ok=E2=80=99 extension. However, I confirmed it = successfully parses received extensions, so it should be easy to process = future extensions from the client when this is needed.

I also specifically = tested this against the Bitvise server (thanks for making that available = for free for non-commercial use!), and it seems to work well.
-- 
Ron Frederick
ronf@timeheart.net



= --Apple-Mail=_B51794CF-B5F1-47CF-BDA8-2092A3C6CA71-- From nobody Sun Apr 26 22:34:04 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996B23A0C5B for ; Sun, 26 Apr 2020 22:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cO0gv6HVohFj for ; Sun, 26 Apr 2020 22:33:59 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0073A0C5C for ; Sun, 26 Apr 2020 22:33:58 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id z17so24238269oto.4 for ; Sun, 26 Apr 2020 22:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7k1mgKvfl5iabHPq2T7C35xiLFmq4/R2h8oQ4ZPrZOM=; b=oZRygU078wGLaumXfULNhVLdehu3KQjwhkkYLQdHAjvjapYj1sO9eB77/DwBTjpLEl Lp5RWAzxo8JOQhWxNWIvAS2xbUb2D9HPHuXM3ghp/SgpnCCRhfXvZLhX58XZuDczcERC N18sD3OdHjebT03hDxTBRohycZvoDbux6G7bVg2u8r6uvIO/EGdHqgEEitzgtY529hJy OJYocHE3rTdD888QY2rIooGWyDe6bL03ebarcoewZbDyM0EkrgHUke/cel/na54bE1ve EldlSN+cDlIRQYDp1JBWsi831YgXffTLPN7mQT9v+sX3ERVfPxTcy8pWpd2OheaTWAkf YsEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7k1mgKvfl5iabHPq2T7C35xiLFmq4/R2h8oQ4ZPrZOM=; b=NnMc+/thuDqKAZ6w5eco/MgEqi6PnL76Jnl3K9erCJD/2sr2uMAsAPe8SnZWHNmSgu KRXYiuEDPgFf1OOZ3YtPKItHZsHVtZrZtHwTnFvjVOwzKt48hilUrT49gULzjs7UQd8G oR3dbZUfa8feeI0J3Vz6ROX+eIIkXDTTJOfDmOeIP9RvvbwuJCUA7gzf214ZVMqrAdk8 4p8A8DR+3qvltqUz7/y1AAf6E8MgjUu82NldN7nhNjvuD9q/c0B65hfijuC4Wgrep7xY OsoFUnzQzCULXlzKM5GXeTKmENo+5dzEwvWogvlhbdS19z0jkIX+a0pD//6f2lG81d8c 6dfA== X-Gm-Message-State: AGi0Pua+6eIzx4jftqPOgeNyLj8Uvzgb36m6R+mE4BDORKlPKg9hho33 tLWjeTeT31C2URfqJA1G3QKAir3IKZGrOJZXogc= X-Google-Smtp-Source: APiQypIl800AYdaxIyf2U3jkVy/feLPDL9jXk9mUKotCTWL+cDn0QXBbnYx72+8J4HMPdlgbuITwQSnVW7kWkUhi97Q= X-Received: by 2002:a9d:874:: with SMTP id 107mr17075779oty.220.1587965637978; Sun, 26 Apr 2020 22:33:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: denis bider Date: Mon, 27 Apr 2020 00:33:46 -0500 Message-ID: To: Ron Frederick Cc: curdle , ietf-ssh@netbsd.org, Damien Miller Content-Type: multipart/alternative; boundary="000000000000c46f1f05a43f0f34" Archived-At: Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 05:34:02 -0000 --000000000000c46f1f05a43f0f34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome! Yes, the idea of "global-requests-ok" is not to make the client do anything different. It's to reassure the server that the client won't violate the spec if the server sends a global request. The main motivating usage case is so the server can feel at liberty to send the global request "hostkeys-00@openssh.com" after user authentication: https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?annotate=3DHEAD This is essential functionality which allows clients and servers to change host keys without requiring administrative intervention at each client installation. Without "global-requests-ok", the server needs a database of client version strings to which it's safe to send the "hostkeys" global request. Otherwise, it can't send it because a bunch of half-baked clients (I'm counting 7 in our list) are borked and can't handle receiving a global request. Or they can handle it usually, but not when they're expecting a response to a channel open. Meanwhile I've received more info about the implementation that disconnects on receiving EXT_INFO from the client. The bug is unfortunately in a widely used Java SSH library. The information I received suggests it's going to be fixed, but I'm afraid there are already a fair number of deployed servers that have the issue. While I'm wishing things - I would also like the "delay-compression" extension to be more widely supported because it's the only delayed-compression mechanism that (1) does not have a race condition by design (zlib@openssh.com), and (2) does not require a second key exchange after user authentication (PuTTY mitigation). denis On Sun, Apr 26, 2020 at 12:33 PM Ron Frederick wrote: > Hi Denis, > > On Apr 26, 2020, at 5:03 AM, denis bider > wrote: > > it has come to my attention that at least one SSH server implementation > (a) advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (= b) > disconnects on actual receipt of an EXT_INFO message from the client. > > This happens when we define a general mechanism, but then the most widely > used implementations only use certain aspects of it. Lots of > implementations now support EXT_INFO sent by the server because it's need= ed > for RSA-SHA2 signatures, but only a handful implementations send EXT_INFO > by the client. > > Bitvise SSH Client sends EXT_INFO if the server supports it. It's free to > use or test with - but it runs on Windows and lots of people don't want t= o > test with that. > > It's possible that your implementation has no need for any of the > extensions that would appear in EXT_INFO from the client. However, if you > wish for this extensibility to be available in the future, then if your > client supports EXT_INFO, I would strongly suggest that it sends it. > > If you want to send a client-side EXT_INFO that takes minimal effort, I > suggest: > > 1. Ensure that your SSH client can correctly handle SSH_MSG_GLOBAL_REQUES= T > received at any point. Your client should not disconnect when it receives > this message, or act like it received a channel open failure if it receiv= es > a global request when it's waiting for a channel open confirmation. These > are the two most common error modes relating to global requests. > > 2. Once you have ensured the above, if the server supports EXT_INFO, send > a client-side EXT_INFO implementing the extension "global-requests-ok" as > defined in this draft: > > https://tools.ietf.org/html/draft-ssh-global-requests-ok-00 > > This tells the server that your client properly implements global request= s > so that the server can use them for things like active keep-alives. > > Implementing this would take minimal effort and would help ensure that > client-side EXT_INFO remains an available extension mechanism 10 years do= wn > the road for SSH. > > > I=E2=80=99ve made this change in the AsyncSSH =E2=80=9Cdevelop=E2=80=9D b= ranch as commit > https://github.com/ronf/asyncssh/commit/b87291d, and will roll this into > the next release. Most of the support was already in place as I already h= ad > common code for generating and parsing EXT_INFO on both the client and > server. The changes are as follows: > > - AsyncSSH now advertises that it will accept EXT_INFO from clients > when acting as a server > > - AsyncSSH will send the global-requests-ok extension when acting as = a > client and talking to a server that supports EXT_INFO from clients > > Since AsyncSSH doesn=E2=80=99t actually have any heuristics around disabl= ing the > use of global requests based on client software/version, it doesn=E2=80= =99t > actually do anything right now when it receives the =E2=80=98global-reque= sts-ok=E2=80=99 > extension. However, I confirmed it successfully parses received extension= s, > so it should be easy to process future extensions from the client when th= is > is needed. > > I also specifically tested this against the Bitvise server (thanks for > making that available for free for non-commercial use!), and it seems to > work well. > -- > Ron Frederick > ronf@timeheart.net > > > > --000000000000c46f1f05a43f0f34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Awesome!

Yes, the = idea of "global-requests-ok" is not to make the client do anythin= g different. It's to reassure the server that the client won't viol= ate the spec if the server sends a global request.

The main motivating usage case is so the server can feel at liberty to sen= d the global request "hostk= eys-00@openssh.com" after user authentication:
This is essential functionality which allows clients and = servers to change host keys without requiring administrative intervention a= t each client installation.

Without "global-r= equests-ok", the server needs a database of client version strings to = which it's safe to send the "hostkeys" global request. Otherw= ise, it can't send it because a bunch of half-baked clients (I'm co= unting 7 in our list) are borked and can't handle receiving a global re= quest. Or they can handle it usually, but not when they're expecting a = response to a channel open.

Meanwhile I've rec= eived more info about the implementation that disconnects on receiving EXT_= INFO from the client. The bug is unfortunately in a widely used Java SSH li= brary. The information I received suggests it's going to be fixed, but = I'm afraid there are already a fair number of deployed servers that hav= e the issue.

While I'm wishing things - I woul= d also like the "delay-compression" extension to be more widely s= upported because it's the only delayed-compression mechanism that (1) d= oes not have a race condition by design (zlib@openssh.com), and (2) does not require a second key exchange aft= er user authentication (PuTTY mitigation).

denis= =C2=A0


On Sun, Apr 26, 20= 20 at 12:33 PM Ron Frederick <ronf= @timeheart.net> wrote:
Hi Denis,

On Apr 26, 2020, at= 5:03 AM, denis bider <denisbider.ietf@gmail.com> wrote:
it has come to my attention that at least one SSH server implemen= tation (a) advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, = and (b) disconnects on actual receipt of an EXT_INFO message from the clien= t.

This happe= ns when we define a general mechanism, but then the most widely used implem= entations only use certain aspects of it. Lots of implementations now suppo= rt EXT_INFO sent by the server because it's needed for RSA-SHA2 signatu= res, but only a handful implementations send EXT_INFO by the client.
<= div>
Bitvise SSH Client sends EXT_INFO if the server supports= it. It's free to use or test with - but it runs on Windows and lots of= people don't want to test with that.

It's= possible that your implementation has no need for any of the extensions th= at would appear in EXT_INFO from the client. However, if you wish for this = extensibility to be available in the future, then if your client supports E= XT_INFO, I would strongly suggest that it sends it.

If you want to send a client-side EXT_INFO that takes minimal effort, I s= uggest:

1. Ensure that your SSH client can correct= ly handle SSH_MSG_GLOBAL_REQUEST received at any point. Your client should = not disconnect when it receives this message, or act like it received a cha= nnel open failure if it receives a global request when it's waiting for= a channel open confirmation. These are the two most common error modes rel= ating to global requests.

2. Once you have ensured= the above, if the server supports EXT_INFO, send a client-side EXT_INFO im= plementing the extension "global-requests-ok" as defined in this = draft:

https://tools.ietf.org/html/= draft-ssh-global-requests-ok-00

This tells the server that your = client properly implements global requests so that the server can use them = for things like active keep-alives.

Implementing t= his would take minimal effort and would help ensure that client-side EXT_IN= FO remains an available extension mechanism 10 years down the road for SSH.=

I=E2=80=99ve made= this change in the AsyncSSH =E2=80=9Cdevelop=E2=80=9D branch as commit=C2= =A0https://github.com/ronf/asyncssh/commit/b87291d, and will roll th= is into the next release. Most of the support was already in place as I alr= eady had common code for generating and parsing EXT_INFO on both the client= and server. The changes are as follows:

=C2=A0 =C2=A0 -= AsyncSSH now advertises that it will accept EXT_INFO from clients when act= ing as a server

=C2=A0 =C2=A0 - AsyncSSH will send= the global-requests-ok extension when acting as a client and talking to a = server that supports EXT_INFO from clients

Since A= syncSSH doesn=E2=80=99t actually have any heuristics around disabling the u= se of global requests based on client software/version, it doesn=E2=80=99t = actually do anything right now when it receives the =E2=80=98global-request= s-ok=E2=80=99 extension. However, I confirmed it successfully parses receiv= ed extensions, so it should be easy to process future extensions from the c= lient when this is needed.

I also specifically tes= ted this against the Bitvise server (thanks for making that available for f= ree for non-commercial use!), and it seems to work well.
--=C2=A0
Ron Frederick
ronf@timeheart.net



--000000000000c46f1f05a43f0f34-- From nobody Sun Apr 26 22:37:15 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A237C3A0C64 for ; Sun, 26 Apr 2020 22:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 1kDRB6r5hqJM for ; Sun, 26 Apr 2020 22:37:11 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257023A0C63 for ; Sun, 26 Apr 2020 22:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1587965831; x=1619501831; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VO9R0tPYGWHF1oKMgxBErKQ9QlbfPCxvPiwCJBQ4DqM=; b=Hgezl8oTPSRa0L/u00sRiFdC1+d/XkC9HbVjQPncLsL32w+1EK5hxWqm I5qFMFs8lO8XP+Ergutl+YHMBV+LU8WLQgWZvb5RFrhkNvw3XPf1fC9Nu io+NZ58PuSTnsxkwjfT1xSe5RY1J6ZwtcSsReDQD+bj7bMqij+unete5a jj8+iLbYmjj3cvam5oLyGStMZRqpen4LgQoW+CEPkJFFUe+ropQ+kge44 o23GwuoGAcVSlvpqpTHzIXlUnzNc681QBvqZ4vfQzla22xIy4DBgB+lkQ LGnR7Fw3Ac88qmyLnq5yQbkK6isPLVVy/S43pQNybtBh6w0G49xzgG6m5 Q==; X-IronPort-AV: E=Sophos;i="5.73,322,1583146800"; d="scan'208";a="130664647" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Apr 2020 17:37:08 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 17:37:07 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.006; Mon, 27 Apr 2020 17:37:07 +1200 From: Peter Gutmann To: denis bider , curdle , "ietf-ssh@netbsd.org" , Damien Miller Thread-Topic: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! Thread-Index: AQHWG8K/y2ILacCI70qZEnF0K8IImaiMdBK7 Date: Mon, 27 Apr 2020 05:37:07 +0000 Message-ID: <1587965828521.34734@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 05:37:14 -0000 denis bider writes:=0A= =0A= >it has come to my attention that at least one SSH server implementation (a= )=0A= >advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)=0A= >disconnects on actual receipt of an EXT_INFO message from the client.=0A= =0A= Not wanting to do a public name-and-shame on this, but could you share the = ID=0A= string needed to fingerprint this server? Looks like a lot of implementati= ons=0A= will need to be able to deal with this...=0A= =0A= >This happens when we define a general mechanism, but then the most widely= =0A= >used implementations only use certain aspects of it.=0A= =0A= That's a more specific version of "an implementation is fully SSH standards= -=0A= compliant when it can connect to OpenSSH (client) or Putty can connect to i= t=0A= (server)". Those two are the universal benchmark for SSH implementations, = for=0A= better or for worse. TLS dealt with this to some extent by adding a mechan= ism=0A= bacronym'd as GREASE for sending random information in extensions to detect= =0A= implementations that broke on them, perhaps something similar could be done= =0A= for SSH.=0A= =0A= Peer.= From nobody Sun Apr 26 22:46:46 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1271D3A0C9D for ; Sun, 26 Apr 2020 22:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UxCuPR0wnFh8 for ; Sun, 26 Apr 2020 22:46:42 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF1C3A0C9A for ; Sun, 26 Apr 2020 22:46:42 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id g19so24207515otk.5 for ; Sun, 26 Apr 2020 22:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqe3PRBYZEVe1vmLyAe/6w31zQJIq3mCMwRU4jwLqe0=; b=Ip8J38aq9FywK+uB3CmV1B6QUgrZndZ7tSRKgxA+BQddcVJuVp4xYBMt7Vu+RWafq7 C8SaOz6goyvNfORJWTEY+CMp96wd/JPgkIomvGFFjC2jasHVexT5stGXmuv7i7/la99T NeTVp+Qx17lAWocYJX5tKRWNc+FtVQOEIyaoNKer5nuZx2k9vGVDWxqzGIZB6eHr9AQN 92PjWa0U5kC7BE3f4QlF4hC/o7eui/fm7VSVAOMxk//CQr3ikmz+RaPJYz+jlR54gPjG aCgpZ9T3qlEaCYK05U2+RNtLhqF6aJbapNKwrKFFdSDYBN6XMEVtgHgnyc3CFJsIsv8Y niPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqe3PRBYZEVe1vmLyAe/6w31zQJIq3mCMwRU4jwLqe0=; b=dpOeuQVRp5XyzZbtzgZHi+UcW02OvcczPPYyoQbuSX9QD1GNJ3466r4/c9LrI7X9KI KMCh7QGY8nNc3J1aVy7eu79z53bsThQkD9wh7cl99Al27HXz/7EiGioHvgapsPJuxxMS 45Gcd2zpSQtLCOUNRh5lxaOotdn+LYHIrchqnD064Sg4PUydroMd1SZkqKmZI60IVR4k bERxacDiIgSuhFYaa06XpOfFYl7FpuqmcfvC6jufKPBN580/EWKZ3gJubELd5KgKUjlq i7c+GzCw7j5Ze67osPpCdpaB6ImisjuGusXAEE3AwKzthzSoriJysOCG/4qTZgxF/ihY o95A== X-Gm-Message-State: AGi0PuYSiQY+joXJsRClyYUku2u6I4cfaZFEi4CzGCPhuvQ6BVSGsvzn 7CHmh6dgCwTWjvwxb8bFV0Kr8pm/IJGlovg63EQ= X-Google-Smtp-Source: APiQypLXtrX/BlTXF84JljFFzJVEySm9h4JRZRyGeMJ54bLmuqOjDAlyB8yNHYBS2E8iqWyB4itfA7RyTTJvCrBYdUU= X-Received: by 2002:aca:2801:: with SMTP id 1mr13945964oix.141.1587966401452; Sun, 26 Apr 2020 22:46:41 -0700 (PDT) MIME-Version: 1.0 References: <1587965828521.34734@cs.auckland.ac.nz> In-Reply-To: <1587965828521.34734@cs.auckland.ac.nz> From: denis bider Date: Mon, 27 Apr 2020 00:46:29 -0500 Message-ID: To: Peter Gutmann Cc: curdle , "ietf-ssh@netbsd.org" , Damien Miller Content-Type: multipart/alternative; boundary="0000000000004620e205a43f3d3d" Archived-At: Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 05:46:44 -0000 --0000000000004620e205a43f3d3d Content-Type: text/plain; charset="UTF-8" Unfortunately, the specific server implementations that use the Java library may use an unrelated version string. Unless I get new information, our next SSH Client version (8.42) will disable sending of SSH_MSG_EXT_INFO if the version string contains: CrushFTPSSHD J2SSH_Maverick However, I suspect the are more and/or the above might not be accurate. At this point I'm pretty sure I've been receiving reports of this issue for a while, but never figured it out because they tend to be ad hoc servers that I couldn't connect to, and I never heard back from users with any server-side diagnostics. This is the first time a user pointed me to a server with which I could test. denis On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann wrote: > denis bider writes: > > >it has come to my attention that at least one SSH server implementation > (a) > >advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) > >disconnects on actual receipt of an EXT_INFO message from the client. > > Not wanting to do a public name-and-shame on this, but could you share the > ID > string needed to fingerprint this server? Looks like a lot of > implementations > will need to be able to deal with this... > > >This happens when we define a general mechanism, but then the most widely > >used implementations only use certain aspects of it. > > That's a more specific version of "an implementation is fully SSH > standards- > compliant when it can connect to OpenSSH (client) or Putty can connect to > it > (server)". Those two are the universal benchmark for SSH implementations, > for > better or for worse. TLS dealt with this to some extent by adding a > mechanism > bacronym'd as GREASE for sending random information in extensions to detect > implementations that broke on them, perhaps something similar could be done > for SSH. > > Peer. --0000000000004620e205a43f3d3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately, the speci= fic server implementations that use the Java library may use an unrelated v= ersion string.

Unless I ge= t new information, our next SSH Client version (8.42) will disable sending = of SSH_MSG_EXT_INFO if the version string contains:

CrushFTPSSHD
J2SSH_Maverick

Howe= ver, I suspect the are more and/or the above might not be accurate. At this= point I'm pretty sure I've been receiving reports of this issue fo= r a while, but never figured it out because they tend to be ad hoc servers = that I couldn't connect to, and I never heard back from users with any = server-side diagnostics. This is the first time a user pointed me to a serv= er with which I could test.

denis


On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>= ; wrote:
denis bider <denisbider.ietf@gmail.com> wr= ites:

>it has come to my attention that at least one SSH server implementation= (a)
>advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)=
>disconnects on actual receipt of an EXT_INFO message from the client.
Not wanting to do a public name-and-shame on this, but could you share the = ID
string needed to fingerprint this server?=C2=A0 Looks like a lot of impleme= ntations
will need to be able to deal with this...

>This happens when we define a general mechanism, but then the most wide= ly
>used implementations only use certain aspects of it.

That's a more specific version of "an implementation is fully SSH = standards-
compliant when it can connect to OpenSSH (client) or Putty can connect to i= t
(server)".=C2=A0 Those two are the universal benchmark for SSH impleme= ntations, for
better or for worse.=C2=A0 TLS dealt with this to some extent by adding a m= echanism
bacronym'd as GREASE for sending random information in extensions to de= tect
implementations that broke on them, perhaps something similar could be done=
for SSH.

Peer.
--0000000000004620e205a43f3d3d-- From nobody Mon Apr 27 02:00:34 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866013A144D for ; Mon, 27 Apr 2020 02:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 b3MI0RRuKzDd for ; Mon, 27 Apr 2020 02:00:29 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2553E3A1348 for ; Mon, 27 Apr 2020 02:00:24 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id g14so24875020otg.10 for ; Mon, 27 Apr 2020 02:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clmCD4OVGFlUWkFWAeEE5VY18Zxxytyh0GJ1w7s4kkk=; b=CiUojHYEhIXEIzLXpF6qBYOfiGzYgKqY5X7NfytfWvG4aytZ0sxY+bEuxhcsIKTSh2 urE/MzgnPs7T39GE6P54mXFqFXlAazCMMiNp9PL0ArITZpUgZkVpucPaLF0R3FEgowUk x+K3aT6PH/2Do4170ZSTuT/LCR9fbL4hjJ03rDGGvm+YO7R5EL/TLZKXvK/ndVXPJ+xL SMXWpItohRWbqJdFxxhHVQDG1pOQoBhjaFjgJQ4d6PziS82H9gvDnzdcLbeYvbZBjlr1 XN41XFE164QKCAwwt5c8X7Dns00ih1bB/sq9j6SGiW/NCMJ+vN2DZj+n/6a+VdsbuX6M lACw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clmCD4OVGFlUWkFWAeEE5VY18Zxxytyh0GJ1w7s4kkk=; b=iNMCJDYmPLrdUmzWoKTj/SrA0fvnbkSI/klJlWc+rmAQFl7LfdXUxiTfo1SIqxbsg3 Sql4FIM9gf8OqGZ6hlcox2W9SEOaR1gK+Lz20NMhyzZEWwdp7L+rqYDLKZvhVR72PO5s dZdB2r2VeFFhmdXu1WocoAp31kWAqB5hZ0sJoLDCRXYfTRN8y4EgEa6muXXTrFMjdtPz A0sN0Tf34WtKt1Ct/rTXCnsubYE2BMqa+slbH1QyWkxD9qOkWlRMJnyvsPbgdElE809h ZsM8glmILry8y116x0DrHWnMsh+3YplEreZP9EyFZjI3NkWkSIawXu3vcvTPetx/CTAf BH9Q== X-Gm-Message-State: AGi0PuZZA5P/XmlRbAw3VHkQsTMKTG3nVsAdxeOCtBZDgtyUVL3jufNB j9P/XLlqFfeHbAB/05DdXLBI4ImCqNoMn/BJi8Q= X-Google-Smtp-Source: APiQypLFtuhsO15x9RwKhdbhBbITcqGAtP+TvGvr1VpQ/UsDAIZ8Si2F6C/1IpwL/Pc+o4YxichnsX7hA+d5lQGm+q4= X-Received: by 2002:a05:6808:7dc:: with SMTP id f28mr3203938oij.88.1587978023317; Mon, 27 Apr 2020 02:00:23 -0700 (PDT) MIME-Version: 1.0 References: <1587965828521.34734@cs.auckland.ac.nz> In-Reply-To: <1587965828521.34734@cs.auckland.ac.nz> From: denis bider Date: Mon, 27 Apr 2020 04:00:12 -0500 Message-ID: To: Peter Gutmann Cc: curdle , "ietf-ssh@netbsd.org" , Damien Miller Content-Type: multipart/alternative; boundary="000000000000fdb2a605a441f1ba" Archived-At: Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 09:00:33 -0000 --000000000000fdb2a605a441f1ba Content-Type: text/plain; charset="UTF-8" About this: > TLS dealt with this to some extent by adding a mechanism > bacronym'd as GREASE for sending random information in > extensions to detect implementations that broke on them, > perhaps something similar could be done for SSH. The challenge with this is that some widely used implementation - *cough*OpenSSH*cough* - would need to exercise all functions of the protocol that are legal, but not necessarily in widespread use. If they want to prevent rusting at the joints, OpenSSH would have to do so for most features, including those they do not CURRENTLY find useful. For example, if a common problem is that clients fail to correctly handle global requests if they receive them while waiting for channel open confirmation - this is a bug that both OpenSSH and PuTTY had, at some point long ago - then the way to exercise that would be to include a trivial global request, in say 10% of cases, before a channel open confirmation. I would welcome that, personally, and hence that's why I originally included Damien in this thread. :) denis On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann wrote: > denis bider writes: > > >it has come to my attention that at least one SSH server implementation > (a) > >advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b) > >disconnects on actual receipt of an EXT_INFO message from the client. > > Not wanting to do a public name-and-shame on this, but could you share the > ID > string needed to fingerprint this server? Looks like a lot of > implementations > will need to be able to deal with this... > > >This happens when we define a general mechanism, but then the most widely > >used implementations only use certain aspects of it. > > That's a more specific version of "an implementation is fully SSH > standards- > compliant when it can connect to OpenSSH (client) or Putty can connect to > it > (server)". Those two are the universal benchmark for SSH implementations, > for > better or for worse. TLS dealt with this to some extent by adding a > mechanism > bacronym'd as GREASE for sending random information in extensions to detect > implementations that broke on them, perhaps something similar could be done > for SSH. > > Peer. --000000000000fdb2a605a441f1ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
About this:

> TLS dealt with this to some extent by adding a mechanism
&g= t; bacronym'd as GREASE for sending random information in
>= ; extensions to detect implementations that broke on them,
> p= erhaps something similar could be done for SSH.

Th= e challenge with this is that some widely used implementation - *cough*Open= SSH*cough* - would need to exercise all functions of the protocol that are = legal, but not necessarily in widespread use. If they want to prevent rusti= ng at the joints, OpenSSH would have to do so for most features, including = those they do not CURRENTLY find useful.

For examp= le, if a common problem is that clients fail to correctly handle global req= uests if they receive them while waiting for channel open confirmation - th= is is a bug that both OpenSSH and PuTTY had, at some point long ago - then = the way to exercise that would be to include a trivial global request, in s= ay 10% of cases, before a channel open confirmation.

I would welcome that, personally, and hence that's why I originally = included Damien in this thread. :)

denis


On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wro= te:
denis bider <denisbider.ietf@gmail.com> writes:=

>it has come to my attention that at least one SSH server implementation= (a)
>advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)=
>disconnects on actual receipt of an EXT_INFO message from the client.
Not wanting to do a public name-and-shame on this, but could you share the = ID
string needed to fingerprint this server?=C2=A0 Looks like a lot of impleme= ntations
will need to be able to deal with this...

>This happens when we define a general mechanism, but then the most wide= ly
>used implementations only use certain aspects of it.

That's a more specific version of "an implementation is fully SSH = standards-
compliant when it can connect to OpenSSH (client) or Putty can connect to i= t
(server)".=C2=A0 Those two are the universal benchmark for SSH impleme= ntations, for
better or for worse.=C2=A0 TLS dealt with this to some extent by adding a m= echanism
bacronym'd as GREASE for sending random information in extensions to de= tect
implementations that broke on them, perhaps something similar could be done=
for SSH.

Peer.
--000000000000fdb2a605a441f1ba-- From nobody Tue Apr 28 16:55:52 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1A23A0AFA; Tue, 28 Apr 2020 16:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vYcf_4ax0Sib; Tue, 28 Apr 2020 16:55:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654463A0AFB; Tue, 28 Apr 2020 16:55:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 12CDAF40725; Tue, 28 Apr 2020 16:55:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, curdle@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200428235526.12CDAF40725@rfc-editor.org> Date: Tue, 28 Apr 2020 16:55:26 -0700 (PDT) Archived-At: Subject: [Curdle] =?utf-8?q?BCP_227=2C_RFC_8758_on_Deprecating_RC4_in_Sec?= =?utf-8?q?ure_Shell_=28SSH=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 23:55:50 -0000 A new Request for Comments is now available in online RFC libraries. BCP 227 RFC 8758 Title: Deprecating RC4 in Secure Shell (SSH) Author: L. Velvindron Status: Best Current Practice Stream: IETF Date: April 2020 Mailbox: logan@cyberstorm.mu Pages: 5 Updates: RFC 4253 See Also: BCP 227 I-D Tag: draft-ietf-curdle-rc4-die-die-die-18.txt URL: https://www.rfc-editor.org/info/rfc8758 DOI: 10.17487/RFC8758 This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status. This document is a product of the CURves, Deprecating and a Little more Encryption Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Apr 29 10:44:04 2020 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3863A14C5 for ; Wed, 29 Apr 2020 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 poY-vL1eln5K for ; Wed, 29 Apr 2020 10:44:01 -0700 (PDT) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A45E3A14CA for ; Wed, 29 Apr 2020 10:44:01 -0700 (PDT) Received: by mail-oo1-xc35.google.com with SMTP id e18so617456oot.9 for ; Wed, 29 Apr 2020 10:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iQuUseg/2FnkmVxRqM3IwtjZkvYOK+1sA5/X5zW7PXc=; b=RGDRkPa55w8tFF39JP2p2KS6hK+S0wwYzo02r33Z7osDdtpWFlNmrcM3u6MP30PjKS UKPFUu0q4kow1sCDVupMBNovARNGc6DrwNuQuuMwQcwN/eLS0aWyu89EXJCX9pMudkfy qA9AxeuOtz/cGykRY5LF1JNQaQv6z9gemNcs3RQ4+gsBKbGplnmAYhJLOVQUP2BR3Lak QShBw4et7SS3NHbPvcgh7rq1lTcBmOxwrvoGCXDjPpEaxYkSYnVLxn+ZHF45mUyYZ2aA Zk0r3M417SMJy/Sn4JKX1ck9iwuWCWneynOrx+x1E0yB2N2G9bjCwkSmUcwM/YAU4qWw LTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iQuUseg/2FnkmVxRqM3IwtjZkvYOK+1sA5/X5zW7PXc=; b=FcSDtnqU85F06uBU353DfdGZ8oFfc5NZi042ZFxBxLS3d7qYffLi0shbxxEkZcUIMX qyeLzapBRFWIHrNti/Gf4qY2UFQP1BDnzIdoqGD5GlTKY7/q4wJoFP6coYEvZ1O6TBrU GX4e7ER3Ag/OUsEEy9+1CR8+WZaQqQT1Ej4fzO/3nHM+vhAxE0j4iPeQ+7nhXBlGH8b3 8HCFY7F1C//HCmIlQkgglJeEzIcdM4eWpMUDNgvOuIN+tVmSqDFjm+je214LfqjPcRRc cZp1YaC8IIKkix+e1F5pvZ6IKvGd6HgUVFKRFolR5HMLl1mkBdstEqwSnua72puyzjWr FtIA== X-Gm-Message-State: AGi0PuYYOCxuFMkoJhWcUMyFduDD2MMLBEJBU6B6nEXrXuXoXqoct1i6 2C2f1ZhI2Xn5I9wcYBh2m8ULpFSLE9HwlSo6p4GMHCjd X-Google-Smtp-Source: APiQypJ/rq5enVPHhUsbJpV5ogwJr7X4wP5uTdg+sFHRQfYPGNNUhras9gx5b+qq4vuQ8KLEzWlnPLHasF50ed8GfbI= X-Received: by 2002:a4a:5747:: with SMTP id u68mr28534917ooa.32.1588182240351; Wed, 29 Apr 2020 10:44:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: denis bider Date: Wed, 29 Apr 2020 12:43:49 -0500 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="00000000000046596b05a4717e2f" Archived-At: Subject: [Curdle] Fwd: Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 17:44:04 -0000 --00000000000046596b05a4717e2f Content-Type: text/plain; charset="UTF-8" Forwarding my below response because it's relevant to previous discussion here. It's worth noting the copy of the message sent directly to Mouse was rejected by his mail server as follows: 550 I don't accept mail from spammers like Google. (See ftp.rodents-montreal.org:/mouse/misc/google-block.txt for the story.) So... that's a statement a particular implementor makes about compatibility. :) If you reject email from Google, that's a legitimate design philosophy, but it's not one most people would agree with in practice. ---------- Forwarded message --------- From: denis bider Date: Wed, Apr 29, 2020 at 12:36 PM Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! To: , > Broken software will probably always be with us. That's theoretically true but practically unhelpful. :) In practice, it matters how much broken software there is. One obscure implementation failing at something is a minor issue, but one major one or several minor ones means a practical implementation which aims for widespread compatibility can't use the feature. Therefore it's important to exercise the protocol abilities we want to preserve to keep the number of broken implementations low, rather than high. > Speaking of which, and I recognize it's possible nobody > here is in a position to answer this, why does EXT_INFO > exist, rather than just using the DNS extensibility > mechanism, with global requests if necessary? I do believe I'm in a position to answer this. I offer two reasons, one from each category: (I) Reason of principle: before EXT_INFO, the SSH protocol lacked extensibility beyond that permitted by adding individual algorithms, without raising the protocol version number. Changing the protocol version number is incompatible with current widespread deployment. In the interest of future extensibility, a generic extension mechanism was needed which is fully compatible with the installed base that does not support it. This is a SSH-specific instantiation of a generic need for extension negotiation that has identified by most popular internet protocols. ESMTP has this, FTP has this, TLS has this, even SFTP has this. Now SSH has it. It fills a retroactively obvious gap that wasn't covered previously. (II) Reason of practical need: SSH needed to transition from RSA signatures with SHA-1 to RSA signatures with SHA-2. This could have been done without EXT_INFO by creating a new key format, but then all existing host key and client public key associations would break, and it would take a decade and lots of difficulty and coaxing to upgrade users. To preserve existing host key and client public key associations, it was desirable to preserve the same public key format ("ssh-rsa") but introduce new signature algorithms ("rsa-sha2-256" and "rsa-sha2-512"). But now there's a problem - during client authentication, the client needs to discover which signature algorithms the server supports without risking a lockout due to an authentication penalty. So the server needs some way to announce this. It would have been possible to come up with an ad-hoc kludge mechanism specific for this, but then this would cost us 1 kludge and it would gain only 1 solution. Instead, I thought it was desirable to expend the cost of this kludge, and gain instead a general solution. EXT_INFO is this general solution. It solves the problem of advertising RSA signature algorithms supported by the server, while at the same time adding a extension negotiation to SSH. So now we have this one kludge (it works by adding "ext-info-c" or "ext-info-s" to a KEXINIT field not originally intended for this), but we gain a general extension mechanism so that, IF WE DON'T LOSE IT, we don't need any more kludges in the future. Why not DNS...? Because the extension mechanism in a protocol should be self-contained. I mean, it would be possible for FTP, ESMTP, TLS or SFTP to have an extension mechanism based on DNS, yes - in principle. Does that seem a good idea to anyone...? It seems an obvious can of worms to me. denis --00000000000046596b05a4717e2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forwarding my below response because= it's relevant to previous discussion here.

It= 's worth noting the copy of the message sent directly to Mouse was reje= cted by his mail server as follows:

550 I don'= t accept mail from spammers like Google. (See ftp.rodents-montreal.org:/mou= se/misc/google-block.txt for the story.)

So...= that's a statement a particular implementor makes about compatibility.= :) If you reject email from Google, that's a legitimate design philoso= phy, but it's not one most people would agree with in practice.


---------- Forwarded message ---------
From: denis bider <<= a href=3D"mailto:denisbider.ietf@gmail.com">denisbider.ietf@gmail.com&g= t;
Date: Wed, Apr 29, 2020 at 12:36 PM
Subject: Re: [Curdle] C= lient-side SSH_MSG_EXT_INFO: Use it or lose it principle!
To: <mouse@rodents-montreal.org>= , <ietf-ssh@netbsd.org>


> Bro= ken software will probably always be with us.

That= 's theoretically true but practically unhelpful. :) In practice, it mat= ters how much broken software there is. One obscure implementation failing = at something is a minor issue, but one major one or several minor ones mean= s a practical implementation which aims for widespread compatibility can= 9;t use the feature.

Therefore it's important = to exercise the protocol abilities we want to preserve to keep the number o= f broken implementations low, rather than high.

&g= t;=C2=A0Speaking of which, and I recognize it's possible nobody
> here is in a position to answer this, why does EXT_INFO
> exi= st, rather than just using the DNS extensibility
> mechanism, with gl= obal requests if necessary?

I do believe I'm in a pos= ition to answer this. I offer two reasons, one from each category:

(I) Reason of principle: before EXT_INFO, the SSH protocol= lacked extensibility beyond that permitted by adding individual algorithms= , without raising the protocol version number. Changing the protocol versio= n number is incompatible with current widespread deployment. In the interes= t of future extensibility, a generic extension mechanism was needed which i= s fully compatible with the installed base that does not support it.
This is a SSH-specific instantiation of a generic need for extension negot= iation that has identified by most popular internet protocols. ESMTP has th= is, FTP has this, TLS has this, even SFTP has this. Now SSH has it. It fill= s a retroactively obvious gap that wasn't covered previously.

(II) Reason of practical need: SSH needed to transition fro= m RSA signatures with SHA-1 to RSA signatures with SHA-2. This could have b= een done without EXT_INFO by creating a new key format, but then all existi= ng host key and client public key associations would break, and it would ta= ke a decade and lots of difficulty and coaxing to upgrade users.

To = preserve existing host key and client public key associations, it was desir= able to preserve the same public key format ("ssh-rsa") but intro= duce new signature algorithms ("rsa-sha2-256" and "rsa-sha2-= 512"). But now there's a problem - during client authentication, t= he client needs to discover which signature algorithms the server supports = without risking a lockout due to an authentication penalty. So the server n= eeds some way to announce this.

It would have been possible to come = up with an ad-hoc kludge mechanism specific for this, but then this would c= ost us 1 kludge and it would gain only 1 solution. Instead, I thought it wa= s desirable to expend the cost of this kludge, and gain instead a general s= olution. EXT_INFO is this general solution. It solves the problem of advert= ising RSA signature algorithms supported by the server, while at the same t= ime adding a extension negotiation to SSH.

So now we have this one k= ludge (it works by adding "ext-info-c" or "ext-info-s" = to a KEXINIT field not originally intended for this), but we gain a general= extension mechanism so that, IF WE DON'T LOSE IT, we don't need an= y more kludges in the future.

Why not DNS...? Beca= use the extension mechanism in a protocol should be self-contained. I mean,= it would be possible for FTP, ESMTP, TLS or SFTP to have an extension mech= anism based on DNS, yes - in principle. Does that seem a good idea to anyon= e...? It seems an obvious can of worms to me.

deni= s
--00000000000046596b05a4717e2f--