From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 1 21:21:01 2016 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 708F112D1BE for ; Thu, 1 Sep 2016 21:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable 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 cGP3sbnaPwTV for ; Thu, 1 Sep 2016 21:20:59 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 E288812D51D for ; Thu, 1 Sep 2016 21:20:59 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 91B4885EF7; Fri, 2 Sep 2016 04:20:58 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EF21D85ED9 for ; Fri, 2 Sep 2016 04:20:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id Y-E7q1o4Oy3L for ; Fri, 2 Sep 2016 04:20:56 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D2A7085ED2 for ; Fri, 2 Sep 2016 04:20:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472790056; x=1504326056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8POLsuakcR0ctp7zvqF2pauSGp0hIgIrQIKqEt5vJSo=; b=v8c4FtPkUCuNDG+Tj0mE56hYmT7f/rF1leR8tCXBEj3LbGjYYUBNniK3 SiAGP5TusxgaucEmFAS9kymoyYhXp3qvBYOdFZhpC5ZIcKfbS8bkESjup a5ExM83AxRq6bhwBbiEz0w6vajwnNNb1Xoo4sx+AmEdasTZ4L43RVYysW pVoX6KN62vAFRGBD3Cq5H9aVH2gQnoyzfHOxsijmgImg+edQs87xHVK+S tlLRxhS84dRHwK2B51+zjOdaVe/TdXLF3mvzYyUaLW3WC9OzaSajSKYgT qE/1TvTX1btKK8OBbIz4i7oVvDsH1ttASc0ohuO8qHCrRyrhIpIsoeoJN A==; X-IronPort-AV: E=Sophos;i="5.30,269,1470657600"; d="scan'208";a="104472723" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Sep 2016 16:20:48 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 2 Sep 2016 16:20:48 +1200 From: Peter Gutmann To: "Mark D. Baushke" , Daniel Migault , Watson Ladd , "denis bider (Bitvise)" , Damien Miller , Rich Salz , Paul Hoffman , "Phillip Hallam-Baker" CC: IETF Curdle , IETF SSH Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHSBJvkjOiuNtoLR0Kry9ftUNzDzKBlmPlj Date: Fri, 2 Sep 2016 04:20:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se>,<28415.1472767053@eng-mail01.juniper.net> In-Reply-To: <28415.1472767053@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list mdb@juniper.net writes:=0A= =0A= >Please advise if there is any consensus as to what changes to the=0A= >https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 are needed t= o=0A= >move the draft forward to a standard.=0A= =0A= As long as there's a DH-2048 + SHA-256 in there as a SHOULD or MUST, I can= =0A= live with it. In the embedded world where even DH-2048 is already a pain, = a=0A= requirement to use any of the ludicrous-speed keys won't go down well...=0A= =0A= Peter.= From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Sep 2 04:28:23 2016 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 E599E12D6B2 for ; Fri, 2 Sep 2016 04:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 frs1tMzErnTe for ; Fri, 2 Sep 2016 04:28:22 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 AD50212D11C for ; Fri, 2 Sep 2016 04:28:15 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E784185EF1; Fri, 2 Sep 2016 11:28:13 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8221385EF0 for ; Fri, 2 Sep 2016 11:28:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id ozkVcOnCXXng for ; Fri, 2 Sep 2016 11:28:07 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 01B8785E85 for ; Fri, 2 Sep 2016 11:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aOHplipHkh8G8q1vNDvQCkmn+6lzyoHGGX6IMimlehw=; b=DKfB7uvboWn4BQKyBJkyj767RlcVIjFVMSEE4grXk8C9fNqCWRUjb6aOujgzZYahUN76/CTThwMTdrpHETSAE4cvU0Y/D+dKTjB59JuAtJ5MIh1e3wPKUAjjHAo+Udn/NB5C6HerpR8PwuJDbDcOKFSk6waqWwEAvDl4qQTKoLA= Received: from BL2PR05CA0044.namprd05.prod.outlook.com (10.255.226.44) by DM2PR05MB335.namprd05.prod.outlook.com (10.141.105.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Thu, 1 Sep 2016 21:57:46 +0000 Received: from BY2FFO11OLC005.protection.gbl (2a01:111:f400:7c0c::110) by BL2PR05CA0044.outlook.office365.com (2a01:111:e400:c04::44) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend Transport; Thu, 1 Sep 2016 21:57:45 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11OLC005.mail.protection.outlook.com (10.1.14.145) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Thu, 1 Sep 2016 21:57:45 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Sep 2016 14:57:37 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u81LvYNh016386; Thu, 1 Sep 2016 14:57:34 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id D83A81141B; Thu, 1 Sep 2016 14:57:33 -0700 (PDT) To: Daniel Migault , Watson Ladd , "denis bider (Bitvise)" , Damien Miller , Peter Gutmann , Rich Salz , Paul Hoffman , "Phillip Hallam-Baker" CC: IETF Curdle , IETF SSH Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> Comments: In-reply-to: Daniel Migault message dated "Wed, 17 Aug 2016 14:35:40 -0000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(5003940100001)(8936002)(50226002)(47776003)(5001770100001)(2906002)(50986999)(105596002)(4326007)(86362001)(2950100001)(76506005)(81156014)(19580395003)(554214002)(93886004)(8676002)(87936001)(81166006)(50466002)(2810700001)(76176999)(48376002)(117636001)(7696003)(189998001)(305945005)(92566002)(68736007)(7416002)(230783001)(15975445007)(106466001)(97736004)(5660300001)(586003)(356003)(69596002)(53416004)(11100500001)(7126002)(626004)(77096005)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR05MB335;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11OLC005;1:usPWAFeIkiHTAZ/wXDaNDAzkTD0VB57dIclvN7MAUitD/+CzjJVPwL9KTbMq4aKr9mrclCPhmpRMdeT21fyTDTiJzx1i1kM3Rjr4Dqv6wElxqlASozIRpD8pf9h4bcdQwtaHEIQ5wFxT5J4zoaZ6qvLgZ8choRgd423BuwL7sk/qdMCXSWn4Vp1tcYNcCb0YXOpneN4cEH0TUpH0uwCfGQtlGDKGOoi27oC0EqIIaimIODV64xC2SNXDAqMGGfC1GAUYaOB92GA97rt/OCdW6ce6/skn6XKAdBLtKjwRpgDiAT1C7DlmxaPzPGH9+PCGdaDRdz+R3uqk4haPIhqpuoDG8sqNVKDND3Pj9w+YWIU9r/YGf/xNUPVunFBKKgQfeOCxF1n4NPxn20byoV111888FlikiKIaX//gMxX/9NlltPU1FiVvoCyyzEr3ooIZvsLKwW29bQ/JUkaXtLs5muD4e6AOhq9a5SBE4rD8A54ud24Pt+a/jN8KpyKQfwmNuwkLGDoV0Jp5JWZ5JloBApP0EgmC93fheG6dhRDTn2I= X-MS-Office365-Filtering-Correlation-Id: d4766baf-7a25-49e4-db5d-08d3d2b30199 X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB335;2:895ckSCKalRzqUcY6Lisa2LWzJlHtBvePlLkLFWNZiZZd88BSl5ntVbVwK7TPtp96by3A5dngIDx6NgUbh6DRcI6gDvxx04D0HiXqw1NzUafpAsHlrv6PZF/5g9BVlfrexmqmy89bf0HAuwsEPF7Jpw5WBFpm6NqnaSStdSZbvLDY3rVU4ypDXC4cWNHGs3G;3:w4OM44ua0iQw6D+dfBwENaHF4mtM1LA6DqYIDDfIPn9SISE4mKJwIChykd66fJJa8KK/ELANwHfo+lpFQyQxQsj+iRxvE7+qZUoa4KzYd55Y3kG2CUrx5JatghmGoqNHk6yShd30A9IkeBGGqVTUVW154qBF/0AcXUk30a411L6ycrH8k9YfjAoITvSUV1PfA29QDgP/8oZ6ofos2jkQhMCiXfIqlqawIvbErx7QiQQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB335; X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB335;25:y2iiJvhxi5zY4Wzzz2KS4/qViB2kJx4yZO/5o+Ua/3NBsjWTJht9We/qEpH745PSII3Tvb1lVMw3+pk92GyYlD4RKt1VNXHmgPopw3+tkwWKE/aYH4WZjZItkXmdFnfuAKEHZJIEdb/V7kZ2hff5Lm0ch7RwEP5nmCOSD4wd3xdgRcfs66J7cE//Y0GBcUUVerWYZGgUQUvoucTXzKbwu6F46WizcpHJj9YkX5F5TYCsLKEs+FghMvzDLR+N8BhIOHAu/1RLUaV+hZur5ib3aPTRs2PMmJX7krbm3spjZy+04Xp8CMWoefUW03CmmZCslH9MPX61PlWUZsAUzqXrpxhilZX0udnLp7q1wNET3rgjn0fpgpMvwhU+tUBizT/xK+Wnu0WW8GSvAQ/fGSJEUDALeeXv8N/urYKZWlo/GblIMYHmdAR+K81D9ecMsSCAE3RdB4JGXrMxTqDoaTzcXtwlwT0taUzfC09h73gYKADB2pOpIURMDw7+Hrb9rAlxb4aOgQ0uoX6U20GQDqHwDnwCSpNgHqU2cPmLeBPAh0/YDKbsa1fVHKUdx+X7JcTPGxKEzxvvrY5ZcUnEhv9pIpVIdh1FXSOltCw5SmSSXkkkuX9WQ2281Hflk0QhD2T47zKSEKi/y9vcs8j2qwXFyudKNzvgqFHBoloYYjZ2xB+TrQfhlRGPvvZicVJhBaf22YXjkpMOJqWtcBfPDpq2J9a6phrzwBS0yGXcq5Rw0e/XeY4kp/BZanp3Mr7Eqf17/4eOxfmDPzYKHIs5lQPToZInc1+iHTxqwHyBO6+po6L44lB7CD/c4VLxagKMAk6mwbBWcIQJZNdP7rEpEvRC/S9FSfCf5yWTTOr79RfACPEReNNxzKf65rgbqdadoS/y X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB335;31:cc6Yd5M8NVVN232SeRs9VwNgWLMLemdxY6EUOGAnmmkGkADGXFplZy/GueoBC8ZgNOTPDzJ+oVWaqnxUpAEr8GOjuo/MtV21U8uwjxj4LPPUogtXPa9Q27hdNhacw21v+gv/jo89ECQux80IcurImlbkclN+5i83szNEwl3vRdrZ7lmjlyDacbcmVtx1b0yVupFGPoj9GXpWZ5/C0NR8ABzdiS7P85A0ySRYMpekFzw=;20:BwCSIOQ3tvttl1FYe6runedaEazV2YZ9coQ/M9QtKAnjTADZ84RpsJVuu2s4SgXyQDrXawde2esrQ6+V1Cu/kVCYGv72hnJoQGP7u/jegFzXJG517AK5qEj9fHABrRlfjP9f/BhrgPldqD16y1Q916gNqsMDEwqv51hPihPWA7QKMhzAu+AweM/mRPHSA+wm+sBLFRaOl/HFvGG346HL3o4vKs+VPiQPcy44Iq5/yN2WIv9K+01o08iYGnekeaCE15rOLn7A7E4LdVZ5lCP0c4jC9NpPhHG1KC274FAjPAYQErbu46wKWxlWgO3RKWuY/ZdIW7HqD8wga2BM7j2Rch32UGkCxvSNK3VeZp0Iuyka68zwEUqxr5r2CMxT8SzilVMzjg+mwlmQLbFLgGkpT98ykfpMz9VJ0JNjfIhf2NUOT2pJgUSF4OlRKehp8m6SJdJDlrkvInUqfcVxDNqbFBL15GDwrng1On9ZURbM5wcXQPZV5+RPDSZaotLwheRs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(788757137089)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(13015025)(13017025)(13023025)(13024025)(13018025)(3002001)(10201501046)(6055026);SRVR:DM2PR05MB335;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB335; X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB335;4:7qFoO3bPawxmzTcOYnawR51LPOZ4wls5vDVlb9EjZdHQObUqTChpQPHtcJ9aLS6Jdq/BWr7fvXZptVASipim0IgG5Lue09+XOtC/V+BMOo/tV5F9AvQDhhgBjVrRVLU35p20vFJs81bv3MNKhTymhY4uBnKdeDq6hgxcnQqOXTGR/McN9JeMIXUEM1FB8wIWd2QXtUswdRF4pVeRt+MrRCkl8dmblcEpagnDGS276D32z8VJMtBhbQw3VzaACQZutJ4O+rC9PuZigem946/SmwJz/ysQxoC9pci1mj8tUlfoizDfPKnemNFnMGla1YIp1U4BaT3xxdCr1EphrFLYGfcYZ/gYQjlw6ARu8P5R4+AtCpx23mGMGQskMPdz0MeEGpF7u7/tRtBJzftTeNrwOd0PQcEc+zPz+q4XLrbXdmrXu8uJ2go0wimcZwQdK+VtiqWS9NtAtlaQ37Hf77ytWKOxp1QsUq1+12bDAytyk9/4XnzqzMKLorSpLAGUvXX8F5cqoUzSBIUcJZzZx7v+SODLwHaJdvrCDFL6SJqLLuIR7iY4TuZSyHjj32nB9CNvDj3twnrNzrpH/JMxUSx1iIXq30EnT8R4zG4Hj0f0cAk= X-Forefront-PRVS: 0052308DC6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR05MB335;23:YEXgRGSO5SMw8iYbDL3j7jgzCU8XVHX6Oj6/dvqysr?= =?us-ascii?Q?UU1GVJTb6ycNAmX0c6B605W8UxWdJxDVUi/c/QxhgEDCH/dPy8OJpSEq3b4e?= =?us-ascii?Q?r89E9Xlx1YZXil30qIZX54biedwgAT8iCz4ZokRe1dEI7UdyAXEj2Dry4boK?= =?us-ascii?Q?uQ5MWarAA5mDTvPjhTqO+j0YZoda1beNwRA1m5L7Od9af4dsuWuz017sONYW?= =?us-ascii?Q?OHFBs3Xyqa2ZcHDR+wiJSfdwoX7f1/fBwlkQ/Fkf0CkbJRYulnOmjgpIoUiW?= =?us-ascii?Q?V5nXpAEhC6sNTnTOE0pVlLMvw/x1nsPBRtpZNbhwFb17HOQVHdbnHoBpIsNV?= =?us-ascii?Q?BKBBpQtRslogQnL2Ew3q9dufAPP2VKzynknBSNz9Fonv1iI8ymX1g0HEl66r?= =?us-ascii?Q?RwMNi4TTbL+/lALSP+C8f1NR4N+2FUdD9kMTDwUZM3twsIp8R+YvSpMjcr7U?= =?us-ascii?Q?Ay7G0hn9Uu28xjd7KzXzmH1joNtA8kTfPnOmzhx5tGkbyj1bMgwjJSCpdOfY?= =?us-ascii?Q?ZuUd5ujZZlwLD2+evLcVNHTKIpbda4aLrwyRKoZOW3/oN94m+B1tcnN4iuh7?= =?us-ascii?Q?EYlDDsquTMPv7hkKpG6E+/6Y6L2Iv7lWE94r1udqOanwuNs/gZcCcRMzAUqX?= =?us-ascii?Q?F/U+m7gi8/u67M27yrV/o6NOY3mPG7+L7MAptabyzoNNLhhwrVzCh8f2n/7M?= =?us-ascii?Q?Pp2lS8AAGN9io7nzDFgsskMwZNjre+K7ePEdagn8WgUauuUbKkK8RDtXevTX?= =?us-ascii?Q?1QinjA0QSw3Y2XjYy83YfTa9FM5DUQc4HwwiUWeDtgjJAyetcOJ1b9v2nHMK?= =?us-ascii?Q?vIBut10bklMblJbNn9IriBuBL9yc0CDvYOTvCjobzV/T7qsr0m4TDAeEm5Ek?= =?us-ascii?Q?lvb2XFjmfDTHN6xPF6KIrZloMWK0NDB+ybjEfNl23dzyujKBIM0ky8atXPDq?= =?us-ascii?Q?b8K6sL9ESqmy4Imgg2wvTquNolRzhPJiUPxxPHRmXFJDl1bscIWJCf5c2QRU?= =?us-ascii?Q?RxoXWErLpVOgKFxV3PQnNG+N6RiYVMDPInsUtWj1/2AbBFWvFZlwT4sALHMn?= =?us-ascii?Q?cIGF4u9xtjrPWsZQh4b1IUXZgsT20wfTin/XqsvCPhDroJooza4jIgniYJmK?= =?us-ascii?Q?llYTaabAcikIEqTt6+d36NzargBK6OrpqDZHeeLR84HQFrM1XzPIWeuiLHuH?= =?us-ascii?Q?345RbKeF7/hp+4+vD5/3cJV9UxXAvZGfsC?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR05MB335;6:pqH5GeYZB/h0PHf5B46zzyAAx9+GGnSXMY5Wutg8tM4Qudn6zrUd1zz/QuR4LooGWcrs5g2wZtA+qPwM1HUx3S58sQV8vrxCC6GMh2nw2GixSufFbkI/el5yAs5u5yaoFTdzxy9hHtYaKRp6hVlqy9YbKIJy3xc8obWfTg9hOiwHEJd5cGaC+At7Xr3EjzNh9LJ/6zSf8VFI55SRr7uhuxAW0+JyrB/WaA18h8EERK8JDu0ZUY7QDYv4yQ+aVhp74wAMLt2bIRcB2oj6nazk0uduFWQlWFf16sb0srhHddIHYZV9PnnYu1UnlGbbcX3NZr+vZ9JRWSwHk3lW5sJwRA==;5:6ZbyybrpVSGlbwkh07Vs4wHBVQ9Za529yvwx0fNLP9fJsEPZn8lkLq0HUrTULsmYcOk+CqNCvFOFN7QMWiQ42+91noqrNex8qQcX5Ov4pmRUhTdWiHI+dITG4iaHdD9eGQw24dUdqJ+D6Pr+zfBhSA==;24:7XLnQ2GEdFDD6b14g25sCaRDoPsa1S00iyeZuPdrTSU88D2nYpnwGpKbd4j7ByekaRcGVX55QkUgNWeYqrl4AeiQ6+DuR7k6NcqteAZ8x00=;7:MTUGzKTBNVLJwbJK6/RPGt0i6vDjynBdFfhLzifCbefHWulmin8I35K0GrIqrjHzNF7lcR1xUB/PTyWsV5Q/tHRaJez9HG+Boo98NKyy5gqgUdmytM1ZNY6Xpu7sJCul0CIiqtHsLzRdF23+HC6EVac5C0CjYwQhmQV+/oHQV94avm533aBcoqS+n9UFnkXd8vvPcLvWyjQzSuKvfiScqfTly7s1kj4P5sPalq9ypNoL0I8Ut5GswhBHBYMLBVSJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2016 21:57:45.6119 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB335 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list My goal with https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 is to deprecate the use of diffie-hellman groups that use sha1 and promote new key exchange algorithms. The latest draft has Key Exchange Method Name Reference Note diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha256 This Draft MAY diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group18-sha512 This Draft MAY It seems reasonable to me to provide a replacement option of a DH MODP group that is well known (already published in another RFC) with a SHA2-256 or SHA2-512 associated hash. (In my view, it is nice to have an upgraded alternative in the Finite Field Cryptography (FFC) key exchanges for the values being deprecated. So, it is desirable to come up with a group or groups that are acceptable alternatives.) MODP groups have been provided in a number of RFCs. In this case, I have tried to choose a MODP group that would drop into the existing kex that SSH uses with only a minor table change for the g,q,p and hash algorithm. I did not try to play games with a MODP Group with 160-bit, 224-bit or 256-bit Prime Order Subgroups like Group22, Group23, or Group24 specified in RFC 5114 because most implementation are probably just calculating q rather than having it in a pre-calculated table. For simplicity, I suggested the groups listed in RFC 3526 which also provides a rough table of security strength estimates. I originally thought that diffie-hellman-group14-sha256 might be reasonable to provide a 2048-bit MODP Group which is already widely deployed along with a hash algorithm (SHA2-256) that should be used to replace SHA1. However, there are those who seem to think that 128 bits or more of security would be better (more than is provided by Group14) and many folks are already trying to get rid of 3DES which has similar security bits to the Group14 2048-bit MODP group. So, either the Group15 3072-bit MODP Group (~128 bits of security) or the Group16 4096-bit MODP group (slightly more than 128 bits of security) using either SHA2-256 or SHA2-512. I suggest that ONE of these MODP group should be provided as a 'SHOULD' implementation as it is hoped that it is a very simple modification to adjust to using a new MODP kex with a new hash in any SSH implementation. I am happy with either SHA2-256 or SHA2-512 as the hash, or even letting the user choose which is desired by making diffie-hellman-- let the Group/hash tuple be provided in the negotiation. Where is one of SHA256 or SHA512 in the SHA2 family. I personally believe the following DH MODP list is too large: diffie-hellman-group14-sha256 diffie-hellman-group14-sha512 diffie-hellman-group15-sha256 diffie-hellman-group15-sha512 diffie-hellman-group16-sha256 diffie-hellman-group16-sha512 diffie-hellman-group17-sha256 diffie-hellman-group17-sha512 diffie-hellman-group18-sha256 diffie-hellman-group18-sha512 I suspect just listing one of them as a SHOULD for now and possibly a larger one as a MAY for use in the future is sufficient. What is the correct DH MODP Group to promote to a SHOULD for interoperability and what should be deprecated? For myself, I am looking forward to curve25519-sha256 as a MUST implementation and letting the NSA/Suite B folks live with whatever ecdh-sha2-nisp{256,284,521} they feel they want to use. Please advise if there is any consensus as to what changes to the https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 are needed to move the draft forward to a standard. Thank you, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 5 18:53:14 2016 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 C3D3D12B00D for ; Mon, 5 Sep 2016 18:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 GtflxmfNyZ1H for ; Mon, 5 Sep 2016 18:53:13 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 A62A812B006 for ; Mon, 5 Sep 2016 18:53:13 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 7B18785E2B; Tue, 6 Sep 2016 01:53: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 EB80785E22 for ; Tue, 6 Sep 2016 01:53: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 aZ41BAyazkGu for ; Tue, 6 Sep 2016 01:53:09 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id D30B184CFD for ; Tue, 6 Sep 2016 01:53:06 +0000 (UTC) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u860eOTZ048340; Tue, 6 Sep 2016 10:40:25 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u860eOeV049510 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Sep 2016 10:40:24 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u860eNPW022505 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Tue, 6 Sep 2016 10:40:24 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id B0967A4F32; Tue, 6 Sep 2016 10:40:23 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id ABED1A4F2E; Tue, 6 Sep 2016 10:40:23 +1000 (AEST) Date: Tue, 6 Sep 2016 10:40:23 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: IETF Curdle , IETF SSH Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <47469.1473112604@eng-mail01.juniper.net> Message-ID: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se>, <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1473122425 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Mon, 5 Sep 2016, Mark D. Baushke wrote: > Hi, > > The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a > week, so I will be publishing a new draft before this Friday. Note: I > will not be able to attend the IETF (November 13-18) in South Korea. > > Here is my current sugestions for the DH entries in the table: > > Key Exchange Method Name Reference Note > diffie-hellman-group14-sha256 This Draft SHOULD > diffie-hellman-group15-sha512 This Draft MAY > diffie-hellman-group16-sha512 This Draft SHOULD > diffie-hellman-group17-sha512 This Draft MAY > diffie-hellman-group18-sha512 This Draft MAY > > I do not see any problems with letting these kex method names be defined > and used by folks that want them. > > The remaining questions are: > > 1) which DH groups are best noted as SHOULD and which ones as MAY > (Peter wants diffie-hellman-group14-*, denis wants > diffie-hellman-group15-*, and the OpenSSH 7.3 release will > negotiate diffie-hellman-group16-sha512 and > diffie-hellman-group18-sha512), > > and > > 2) is the use of sha512 vs sha256 vs allowing either of the sha2 > functions to be negotiated best to use for the new DH groups? > > As you can see, I am currently tending toward not having any of the new > DH groups be labled as MUST. > > The -04 draft would therefore list curve25519-sha256 as the only MUST > kex method. > > Are there any strong objections to this direction? Sounds good to me -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 5 22:01:32 2016 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 5C34712B093 for ; Mon, 5 Sep 2016 22:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 E0Ryr486WlyS for ; Mon, 5 Sep 2016 22:01:31 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 4BD6612B01C for ; Mon, 5 Sep 2016 22:01:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 07EDB85E9A; Tue, 6 Sep 2016 05:01:30 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id A696885E80; Tue, 6 Sep 2016 05:01:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 62C0085E69 for ; Mon, 5 Sep 2016 23:12:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id OmIdLXdUYuDS for ; Mon, 5 Sep 2016 23:12:45 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 10B9285E2B for ; Mon, 5 Sep 2016 23:12:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=EGjZ0ImDKM7RLODGqV7DCehftE1mQdDltdZDsLIRBnY=; b=DFez6NvyH+SG3C0ztk+coZWnr30jS0lw5cX9aSvCTUo59Mcj73wB7njiyumZo5B3V295kYdd7NvvN AWlZsDQc7k0bNYw+kTRIK4Eu8ReOWhnFxwO6lHWzCJGCbkKmF52OvmguLLnFr4HyNwnMlUdahnMMiW vxHcUChBvWBWUNPV0QvawemRLfb1I8l1lJpQlS3iS3cP1OgsCY8OOMp7+9o44SAQOZZbkYDJC1ogBe SucwfCt1wW0XzvpIwes/IqqBDNYG50lEUrFaiqB0pCSDY0P4dwN1YFIWc1gmg5lbbzVFzSl9L/Mbel W4H9nZT5rZSwVNHVNb4HE6TDLT3QWIQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 6 Sep 2016 00:12:36 +0100 Message-ID: <132FC1F9E8554923A4262A151364F73C@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , "denis bider \(Bitvise\)" , "Damien Miller" , "Mark D. Baushke" Cc: "Daniel Migault" , "Watson Ladd" , "Paul Hoffman" , "Rich Salz" , "Phillip Hallam-Baker" , "IETF Curdle" , "IETF SSH" References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se>, <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> In-Reply-To: <47469.1473112604@eng-mail01.juniper.net> Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Date: Mon, 5 Sep 2016 17:12:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D20798.A7F52510" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000A_01D20798.A7F52510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support the described change intentions. With regard to question (1) about MAY/SHOULD =E2=80=93 I don=E2=80=99t = have a strong position. In my implementation experience, end users = don=E2=80=99t care about these types of recommendations, and the = recommendations do not stand the test of time. Our security conscious = users knew they wanted to disable CBC before there was a spec about it. = Our users now want Curve25519 and Ed25519, and they don=E2=80=99t need a = =E2=80=9CMUST=E2=80=9D to tell them this. The main reason I see to impose a SHOULD / SHOULD NOT is when the spec = can inform the implementer about something that=E2=80=99s not obvious. = For example, if I=E2=80=99m an implementer of desktop and server = software, it may not be obvious that I should offer a key exchange = method that=E2=80=99s feasible for resource-constrained devices. So, for = interoperability reasons, it=E2=80=99s good to make group14-sha256 a = SHOULD, and also to state the reason for this recommendation: = interoperability with resource-constrained devices. With regard to question (2) about SHA-2 versions =E2=80=93 I would = prefer only SHA-512 for group 15 and higher. Group 14 should use SHA-256 = because it=E2=80=99s for interoperability with resource-constrained = devices. Group 15 and higher need a way to be used with a 384-bit hash = or larger to meet those irrelevant government recommendations no one = likes to hear about. An implementation that can do 3072-bit DH can also = do SHA-512, so I don=E2=80=99t see why not. In summary, I think the proposal is fine. denis From: Mark D. Baushke=20 Sent: Monday, September 5, 2016 15:56 To: Peter Gutmann ; denis bider (Bitvise) ; Damien Miller=20 Cc: Daniel Migault ; Watson Ladd ; Paul Hoffman ; Rich Salz ; Phillip = Hallam-Baker ; IETF Curdle ; IETF SSH=20 Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 = Hi, The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a week, so I will be publishing a new draft before this Friday. Note: I will not be able to attend the IETF (November 13-18) in South Korea. Here is my current sugestions for the DH entries in the table: Key Exchange Method Name Reference Note diffie-hellman-group14-sha256 This Draft SHOULD diffie-hellman-group15-sha512 This Draft MAY diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group17-sha512 This Draft MAY diffie-hellman-group18-sha512 This Draft MAY I do not see any problems with letting these kex method names be defined and used by folks that want them. The remaining questions are:=20 1) which DH groups are best noted as SHOULD and which ones as MAY (Peter wants diffie-hellman-group14-*, denis wants diffie-hellman-group15-*, and the OpenSSH 7.3 release will negotiate diffie-hellman-group16-sha512 and diffie-hellman-group18-sha512), and 2) is the use of sha512 vs sha256 vs allowing either of the sha2 functions to be negotiated best to use for the new DH groups? As you can see, I am currently tending toward not having any of the new DH groups be labled as MUST. The -04 draft would therefore list curve25519-sha256 as the only MUST kex method. Are there any strong objections to this direction? Thanks, -- Mark ------=_NextPart_000_000A_01D20798.A7F52510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I support the described change intentions.
 
With regard to question (1) about MAY/SHOULD =E2=80=93 I = don=E2=80=99t have a strong=20 position. In my implementation experience, end users don=E2=80=99t care = about these=20 types of recommendations, and the recommendations do not stand the test = of time.=20 Our security conscious users knew they wanted to disable CBC before = there was a=20 spec about it. Our users now want Curve25519 and Ed25519, and they = don=E2=80=99t need a=20 =E2=80=9CMUST=E2=80=9D to tell them this.
 
The main reason I see to impose a SHOULD / SHOULD NOT is when the = spec can=20 inform the implementer about something that=E2=80=99s not obvious. For = example, if I=E2=80=99m=20 an implementer of desktop and server software, it may not be obvious = that I=20 should offer a key exchange method that=E2=80=99s feasible for = resource-constrained=20 devices. So, for interoperability reasons, it=E2=80=99s good to make = group14-sha256 a=20 SHOULD, and also to state the reason for this recommendation: = interoperability=20 with resource-constrained devices.
 
With regard to question (2) about SHA-2 versions =E2=80=93 I would = prefer only=20 SHA-512 for group 15 and higher. Group 14 should use SHA-256 because = it=E2=80=99s for=20 interoperability with resource-constrained devices. Group 15 and higher = need a=20 way to be used with a 384-bit hash or larger to meet those irrelevant = government=20 recommendations no one likes to hear about. An implementation that can = do=20 3072-bit DH can also do SHA-512, so I don=E2=80=99t see why not.
 
In summary, I think the proposal is fine.
 
denis
 
 
Sent: Monday, September 5, 2016 15:56
To: Peter Gutmann ; denis=20 bider (Bitvise) ; Damien Miller
Subject: Re: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 
Hi,

The=20 current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about = a
week, so I=20 will be publishing a new draft before this Friday. Note: I
will not = be able=20 to attend the IETF (November 13-18) in South Korea.

Here is my = current=20 sugestions for the DH entries in the table:

Key Exchange Method=20 Name           &nb= sp; =20 Reference    =20 Note
diffie-hellman-group14-sha256      =   =20 This Draft   =20 SHOULD
diffie-hellman-group15-sha512     &nbs= p;  =20 This Draft   =20 MAY
diffie-hellman-group16-sha512      &= nbsp; =20 This Draft   =20 SHOULD
diffie-hellman-group17-sha512     &nbs= p;  =20 This Draft   =20 MAY
diffie-hellman-group18-sha512      &= nbsp; =20 This Draft    MAY

I do not see any problems with = letting=20 these kex method names be defined
and used by folks that want=20 them.

The remaining questions are:

  1) which DH = groups are=20 best noted as SHOULD and which ones as MAY
     = (Peter=20 wants diffie-hellman-group14-*, denis wants
    =20 diffie-hellman-group15-*, and the OpenSSH 7.3 release=20 will
     negotiate diffie-hellman-group16-sha512 = and
     = diffie-hellman-group18-sha512),

 =20 and

  2) is the use of sha512 vs sha256 vs allowing either = of the=20 sha2
     functions to be negotiated best to use = for the=20 new DH groups?

As you can see, I am currently tending toward not = having=20 any of the new
DH groups be labled as MUST.

The -04 draft = would=20 therefore list curve25519-sha256 as the only MUST
kex = method.

Are=20 there any strong objections to this direction?

Thanks,
--=20 Mark
------=_NextPart_000_000A_01D20798.A7F52510-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 6 07:37:19 2016 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 EAE6E12B27F for ; Tue, 6 Sep 2016 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 EUCpd1BdsIXy for ; Tue, 6 Sep 2016 07:37:14 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 204C612B496 for ; Tue, 6 Sep 2016 07:33:49 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E247285EB0; Tue, 6 Sep 2016 14:33:46 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 954A985E83 for ; Tue, 6 Sep 2016 14:33:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 WzqCmO5QtS-f for ; Tue, 6 Sep 2016 14:33:43 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::722]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D2ABE85E5B for ; Tue, 6 Sep 2016 14:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dE7HuoPKkTcE830Dc5luQnFBKx+KdS52tLsW/csBOWw=; b=IbLFngFxcpOOpR1N56kRl0jd/Ay7ypHA3Y3vB5YbALvvBrHeaLwOHpiTvZxr2mM32XCLhP8SdDwRRPq3Bchvf/+NsOSG3kI3KzP0FZMHMXX9g0u6RfDBKr4WHcwoP15CIjQWIZBPQDjmoD2B5sFI67TXxws9Q5qUDqeG3KvHGxo= Received: from BY1PR0501CA0022.namprd05.prod.outlook.com (10.162.139.32) by MWHPR05MB3151.namprd05.prod.outlook.com (10.173.229.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Mon, 5 Sep 2016 21:56:48 +0000 Received: from BY2FFO11OLC009.protection.gbl (2a01:111:f400:7c0c::129) by BY1PR0501CA0022.outlook.office365.com (2a01:111:e400:4821::32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend Transport; Mon, 5 Sep 2016 21:56:48 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11OLC009.mail.protection.outlook.com (10.1.15.0) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Mon, 5 Sep 2016 21:56:47 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Sep 2016 14:56:47 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u85LujP3011792; Mon, 5 Sep 2016 14:56:45 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id DAEA41141B; Mon, 5 Sep 2016 14:56:44 -0700 (PDT) To: Peter Gutmann , "denis bider (Bitvise)" , Damien Miller CC: Daniel Migault , Watson Ladd , Paul Hoffman , Rich Salz , Phillip Hallam-Baker , IETF Curdle , IETF SSH Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se>, <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Fri, 02 Sep 2016 04:20:47 -0000." From: "Mark D. Baushke" Date: Mon, 5 Sep 2016 14:56:44 -0700 Message-ID: <47469.1473112604@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(46034005)(199003)(586003)(97736004)(93886004)(47776003)(2906002)(2950100001)(50466002)(117636001)(77096005)(76506005)(106466001)(2810700001)(5003940100001)(230783001)(189998001)(7416002)(5001770100001)(305945005)(11100500001)(48376002)(8936002)(54356999)(81166006)(5660300001)(7126002)(81156014)(356003)(7696003)(105596002)(69596002)(53416004)(76176999)(87936001)(626004)(68736007)(50986999)(4326007)(86362001)(8676002)(92566002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR05MB3151;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11OLC009;1:tB5GEAaURu+HC3gwlhFiD3+GB8snDj1bkfRpveyYl6fip4KUdLKMohX7ifUMOQdTIB+GSuuwTiMJpaSs/06fUkPWLHqgoRgSSZ/clUpZ+bhvUs7YW+zwVrZZg8NewuuT0Lhm9ONpbVRdIDb7XoyjlgViu6sUJZ1MMCgdZ4IGZ3xHjPcA0Sfx98uiTewR867SpY7GhydNVtySLosG/iGj9paIZItpw0w5ux1Y4DNcKZGxKNXoNiGImUsL2dv/mIpujRDrzcpG8RcRVLsdinGvngOuyTyH+AP3Ba17IgqO/O+X+tB7K6Ac3EoKJqEp8R1i/YflyJFryvfOzUN/jFJ9q3H/fNBwVkm0ycUNHKL7VNLeWhKqsZ3XhW3zwba1q/IdW7EFD5MW+ba08GQUkhzhqwCMAWSV7IAGBuyKOFhcmC9tuf6vGCHbemDEGP3QAkt3c+d+eP8tf19EuTzsNwlu74xpC8UQ9KDDvJWdtiMgl4JdZnIxropGnvkPOpPeD0r/03wE1WgQfQlh4gkmsVrZIL81Ap4C3xB5ju/DheKARWKIvMo+m7GXpPbXIIGmcxlWAReNa/hdlxGC9gsjiV+qmA== X-MS-Office365-Filtering-Correlation-Id: e8c2bcd3-d3bb-4745-1593-08d3d5d788e9 X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB3151;2:4dCZ3lzO1y5e0AKZsR+FDJsnt1ECd609myXElrvaNuGonKmHczSzn2DtSoeWhKQe0MrSXusyjH3+AgFsllQfIHToSbVpCwJjIu6w9cW5JxMEnSMTKqhd7ZITYqwT9907xEoQPR0+ssFmKFXf4jr+Nhf7C0MepPg/V80cCIXse15ufjXMuQHi5hvjANG9TjPu;3:huoVR04u5bjdsl7o1wgveLpk29lBVggZgFoiwh1lHeBK/U+s6nk7RwUjrQEjRpmN+Ub2Nb3d4cnj0DGmDVJCjuvKp0CC/ReYcrL3xTcNY9lN/EIfsH9d8gv0bs3aEV9JGDTS42zS1Kp4PAPGKMx4Ao5wiVsVAZ8DfQZNru5jk33ac1zqLfQpoJtZJum2x6N+h88ZtrK9xHn3q2mLqZ0JqOxAkJfurYoW5TkXagu3UVw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB3151; X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB3151;25:SaMqoAvdvr6LSDxER222HKHTR591vf/ClmY7emYEBQvc/54Hw4FQvZmNYwndpVD5GIy6KpwQNobxEvAXCYqCcpJmo3wFLlOVSPUxeryINUr/w3/6w6QXHqXtYhZ9uNXsjvOCTNvuvJKY6pv6cohbr6ovhQpclPXIExL0xf7R5b4OAXIbFo6EXz4TAVWyFR51c5ww4zsMZwxtSvVluvKyx2+Q0wxw7VSTYHRlBqLdvy3tx70fWyZtf58jAGikoDwPTT9Q8GrEEZq7UmQo5wcrC0YlEVQvpV612b3J0Mgh4u1/o6ppdHVDgT7VQ08bajpETmJ2pG2d/ldGdOgIpTP0tkLS2Gy2eSweFpxg19wn6wPZ6xOYlwDyXolw5HIgmpvZ3xsspEEGzpK9B21/A3BqvvumrbnnyVeM5phqoyOSjIDV+n3bfp0yy/wkAE28mcP706I4fkbRGPKpM0480GvVllZ2QZuoCfB2cyjXh86ZVMgsXQAOPgPBiV1RiDNEL7LLd3tlNqCyH2ypdpnvKEsu+7Yr/E2HQmjPmSVEIhE2UrSrnl/Zkml4Tf7qzo+fGBGhFXs1dlUQ77fIn6YbnVwI8VVDAwmrvHuQ6p8WUP07GDRWtyRZWxv8+kYB0EAXwXWFsS7cQs37zsOi6wPRKkuZIZfO3yLiOc2KPBXsd3pRYF+Aq0gshd+pyXCQe561N9QPFeRuX623B3Gn6s/aZ7T2JDL8W0UOdd5gjIjFBXfPYgaTcmx0kc6J8bi7yWeEaW8a X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB3151;31:tvnhwaCpudp8OPkKLo8IGeNVHzx657LLlzZdwE1WWvPZi9aZFJjQm6k2opR1LrAAwv5UwRR78wIlxpBCAaGqHrORfNtu8i6OjQQkPtkXw4hg8PrpcjzPPsCCi46+QPgrg8U/4f9Qji4dTbWDbPuDj1VMWpfFG31b+0T4aN+YQ7sEYRaOz2ld+Yoc4cLnJadrLyXLyzKn6vkt799b6WupRK5ehXHPbUf6RdgREPL/27E=;20:4o48hLap6Jwigo+vdjo3j/FRq+S026PIDIxmGWNse1W+K6nVo9OQqQSb1m3zWZH/cJQAMvLKenX+k+rEoBWPI7qqrqAA/TSUn61Ab7VTHz8U1xfSFrCo5AfrMnVJtdtBBMAmg98dCNzW9KHYM5IZLnsA31D6WBz4Sp10Fq3DkAEI9rCey15AcMyXyTO6CSIEcdrXmHGVpMrKKKaxYgLgpA031i9CTalVO7WgdvyrfOYNW4dP+LJy78MGNq6UGCNk6Kxm+WpVh96XvvnmZXAxIJbyYobhIagnKC2SwgFRBdROHLcmPAZSzwEXBE6KQM9Nquk49t8iwFfVSk5EJ4F1m6R8JZXLP29mzF+nufLlLDhssf65bCcJRTEfIewtJQGu8YGInC8qistkUW7bAh3pXOgz+7q3q0uVh3wuikmg5m+ASVzyPbpvQM/95nOCmeeXKWZY/Sr+Jx57B0pu2a5IO7vNnTKPpSyODRYzSnLwMAIWbXzFH2m8VTBZGDeelhG0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13015025)(13018025)(13023025)(13024025)(13017025)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:MWHPR05MB3151;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB3151; X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB3151;4:MSLDoSNIHFUn/nGqKTfe/c1EZRsMtG9jIxQTohTsy/T5mTU+/zQc+T2JvAF1zMBNM+WJm1gNkDBNwLsOC38GnrSXWn52Wht1qmpUacT22WUPkJGGJRj1IW9vEz+Bthsn3CPE98gKdkQ570ZflLNZF8AFNIusMlOTedVssMl/FGHyCGSu7wfLVxXYEoobrxcCzk9IoWYLgayC6OGi2h51QJhydXdqYcLMCkKDfrs2et6tf9BuqBsdso4BQjRp+eliL7mEGIUS5OGggnJy2PqdXXILDQvYvnrsDtyjVl6Cn27Aojuhd2+fzGLXGvw9Qc4a6bdxoxb/kTjEgE2jSvCvv1MyRwk6SGYY2Mx7mlrDj6ErMjddbH8uf2AZHhmOzlOY/PbRRSN0w1i2LJifGenr3mhr0dfSV2bo8T0xUKdAPQ5oUymM869n1PAbJA18MrJXNRJ/gvTewKrkm+vaMeBAxxMNAZDxTQgetbHrFHHYTFmwByXLgJQYgabdBlhqVoU5 X-Forefront-PRVS: 005671E15D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;MWHPR05MB3151;23:4XM192x9ehlIqS5tt0fSS+WrkgUZXBhlCh4YfZHSM?= =?us-ascii?Q?N/6B0nVwca0n2bW3jQtPYR0cx1Q3x8TAO0YaNzpkOvoQ+v+MtAIlbjkxeH+v?= =?us-ascii?Q?6ZcJmO9/1ylcvwZD1JkrIWDrX9ziLqaEQdCEfOConmxQiYXRZPy1akUw1dsL?= =?us-ascii?Q?E4B72ESp/Tc0mkqnjJh/kifcRJlU3cyY/CDvgpsy9+LkmfUXZ9mwrdkMcdwl?= =?us-ascii?Q?qWm1fGa4b6nW/WOtL4+qVCmjXiMEVD2UmJsX4afDns/K/SwAASrGZffTvVke?= =?us-ascii?Q?x5dpVMS35E7XPTD8IVNvVc8HGnSaHKzwl+GA8Hr4f0R0sWd21J+PUXJynjeY?= =?us-ascii?Q?8/HSm4oxrSvPtophaYveKXw6J3py3+oDPf6VWcQUCJ8JNX4nOEUPIzWujxwE?= =?us-ascii?Q?1JBfseFhWwfiBqNB1A6DhnJ541J0yvXIRagFHt6mxAtG024051CXqIoD0Y6n?= =?us-ascii?Q?/OJ4eecP3URzJcVnGo6sDCMZXMX1SME/wTU2ZckUMXv32nqMWb+NNQ3LLxls?= =?us-ascii?Q?5//rN9d6KIPsRoNGRSZKuVHZ+S2+E3zGYiP1KQDb8nIGQ6UkIw000rYb5Peh?= =?us-ascii?Q?Pz6hBQG0y9HBxx0CTchLNTJdIhUiFbL7uW4TERArkDgd0oMuL8dPs+WXGHds?= =?us-ascii?Q?S6wHxvahSJ6VaOfo00DWsf2bZR37IyF+NOYC48QBwmnP+ylmK3PJ29wpNjST?= =?us-ascii?Q?ss4BLKjDQIKMr9DcymnrFzbWkQyNo8rQ1KFNWH++MtOhKG4ECUN0Qa9H1dyd?= =?us-ascii?Q?YD36ORKJZ+Jr/Ly2uRJ0zrETjXHBj6mepiLOnVlQk5FJmCSlZmqt650JCxud?= =?us-ascii?Q?yfuRTjq5S2eTICmihKd/pdXM5zvoxbfkaguOa5J78i1mt+C++P8YmeQCOxKp?= =?us-ascii?Q?DtcyWeab93hnx3AJCbZ0+HNEAEZslywuDTjzFd77yCd/NFjSSAysyRYHQpr5?= =?us-ascii?Q?PL+GSPyYpW7/QgcPAPBBPqMgV9CsEr/q2kBPSSIHlo473T3vf8Bvuilyud5I?= =?us-ascii?Q?LwPXPrTknNKOdw2eElxYfRJehGaRKD3+hb8Q4TL79XPVfHObLNfTKa8V0fBI?= =?us-ascii?Q?gJ4BSHAKK/ALA5A1M6aIzByAwfDonux2xGl16Pxr5tmGzB6xa6e9o6JnH2ga?= =?us-ascii?Q?AJLn5FQMv3rwZ6AV7twhWVt18jxL+pf?= X-Microsoft-Exchange-Diagnostics: 1;MWHPR05MB3151;6:EnZ7Qbt+5WwDrIqHvOSXDaGiH5Kmj4prahU9vevF+W9aJjVZ/qg6OmwPZIO/uSdU6e8RSLlNxnTWhZgowr821CwnQxYQe1dJ/vzH9QyfbTYgocZ0Jkzl2okxT7UyUlybE1rtzuTm+KN5sTdezkXZ7+8xcZaCEr3Y4ghFrc3sBwKxSucSx/yYmcFrnFFgThVG2Vrn6y/Yop2SGQTmHT/kX2DOD9AjUnzr9X2ALYq8I7BTR09YnY4HRL/sEcJ3P7Yogvrv2RXcSM4jP9S2lkgum02fnz7cYdcTZeHBqCrtXrLDcKXRSgOt+7wXFZEiBwYqBSioRAybzoUyQzdLHePr5g==;5:dGIVw9nJGRGVaghPCIA5/vKNDMJPKEqTnZMz/Emt7QjeK6NKoOnE88CPzHKDsXlR7PLJ09y9Gp7svxNGZ+0uvM9BEehy8cMZ/SXRu3NTcYS0lYpEhxXGgesyd7FvAmq5jx62ltwHNWdx7Qp54PFerQ==;24:wbfQIZ9quwXaJkmDWlf+hgWZHitQ0BIH6mZCrf/BXmwFPGCf7yiptgAVj1e3uIGL3p/bd5PvIGYsrmLuWpaN2aSpk/vlDIAhCtEXoIeC8s4=;7:/3SF1P5m8oo63D1YJN/iaDkh6o0BjXpoJuThFLw3O/0jYLzIwnEzbG91CHjszqFFq9aqW8h41DKNzJxN46K6pwM2fe5kWfbaISqV8OlLy+/hz2JdRV8QBJeIMbMSR0WzFSqHWUtKrDxAfbktGhfqURR/OG5nfOHaEbZgvY7mrPprwM/OKHR6WAE5BkgjVrbrzZSncZGk5qorjWrsIAW1mw2lc3MAjtV8NauI+2XfVvCIAx091cPxdEkiMrwjL1/C SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Sep 2016 21:56:47.8693 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3151 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a week, so I will be publishing a new draft before this Friday. Note: I will not be able to attend the IETF (November 13-18) in South Korea. Here is my current sugestions for the DH entries in the table: Key Exchange Method Name Reference Note diffie-hellman-group14-sha256 This Draft SHOULD diffie-hellman-group15-sha512 This Draft MAY diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group17-sha512 This Draft MAY diffie-hellman-group18-sha512 This Draft MAY I do not see any problems with letting these kex method names be defined and used by folks that want them. The remaining questions are: 1) which DH groups are best noted as SHOULD and which ones as MAY (Peter wants diffie-hellman-group14-*, denis wants diffie-hellman-group15-*, and the OpenSSH 7.3 release will negotiate diffie-hellman-group16-sha512 and diffie-hellman-group18-sha512), and 2) is the use of sha512 vs sha256 vs allowing either of the sha2 functions to be negotiated best to use for the new DH groups? As you can see, I am currently tending toward not having any of the new DH groups be labled as MUST. The -04 draft would therefore list curve25519-sha256 as the only MUST kex method. Are there any strong objections to this direction? Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 6 13:22:53 2016 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 3DD8212B420 for ; Tue, 6 Sep 2016 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 HKb7a_5_VLxJ for ; Tue, 6 Sep 2016 13:22:51 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 9CF0812B41C for ; Tue, 6 Sep 2016 13:22:51 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8DEB485E77; Tue, 6 Sep 2016 20:22:50 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 480C985E5C; Tue, 6 Sep 2016 20:22:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1373C85E58 for ; Tue, 6 Sep 2016 14:59:18 +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 5WQRFNc68mli for ; Tue, 6 Sep 2016 14:59:17 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 2AB9585E22 for ; Tue, 6 Sep 2016 14:59:15 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id KAA09902; Tue, 6 Sep 2016 10:59:06 -0400 (EDT) Date: Tue, 6 Sep 2016 10:59:06 -0400 (EDT) From: Mouse Message-Id: <201609061459.KAA09902@Stone.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: Tue, 6 Sep 2016 10:50:05 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <47469.1473112604@eng-mail01.juniper.net> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se>, <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > The -04 draft would therefore list curve25519-sha256 as the only MUST > kex method. Speaking as an implementor, albeit of a relatively fringe implementation, I do/will ignore anything that mandates elliptic curve algorithms. Whether this is worth paying attention to, of course, I cannot say. /~\ 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 Tue Sep 6 13:23:18 2016 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 62E9812B420 for ; Tue, 6 Sep 2016 13:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 iZDKFqNLRyh9 for ; Tue, 6 Sep 2016 13:23:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 CA68112B41C for ; Tue, 6 Sep 2016 13:23:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8CCB385EAA; Tue, 6 Sep 2016 20:23:16 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4017B85E96; Tue, 6 Sep 2016 20:23:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2F3FB85E22 for ; Tue, 6 Sep 2016 13:13:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id nw7cU1zpzWoR for ; Tue, 6 Sep 2016 13:13:37 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3F69785DFE for ; Tue, 6 Sep 2016 13:13:31 +0000 (UTC) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u86DCDp1011447 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Sep 2016 16:12:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u86DBmSe027695; Tue, 6 Sep 2016 16:11:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22478.49300.27045.788996@fireball.acr.fi> Date: Tue, 6 Sep 2016 16:11:48 +0300 From: Tero Kivinen To: "Mark D. Baushke" Cc: Peter Gutmann , "denis bider \(Bitvise\)" , Damien Miller , Daniel Migault , IETF SSH , Watson Ladd , IETF Curdle , Paul Hoffman , Rich Salz , Phillip Hallam-Baker Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <47469.1473112604@eng-mail01.juniper.net> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 16 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes: > The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a > week, so I will be publishing a new draft before this Friday. Note: I > will not be able to attend the IETF (November 13-18) in South Korea. > > Here is my current sugestions for the DH entries in the table: > > Key Exchange Method Name Reference Note > diffie-hellman-group14-sha256 This Draft SHOULD > diffie-hellman-group15-sha512 This Draft MAY > diffie-hellman-group16-sha512 This Draft SHOULD > diffie-hellman-group17-sha512 This Draft MAY > diffie-hellman-group18-sha512 This Draft MAY > > I do not see any problems with letting these kex method names be defined > and used by folks that want them. I think it is bad idea to define too many KEX methods. I think there should only be two, one with sha256 one with sha512, i.e., diffie-hellman-group14-sha256 and diffie-hellman-group16-sha512. The reason is that these key exchange methods are negotiated in text. We already have key exchange list in openssh saying something like: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 (150 octets), and now when we add to this list new methods: ,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512 (another 150 octets), it gets to 300 octets, just to negotiate the key exchange methods. And this string is sent in both directions during the negotiation. Also I do not really expect most of them to be used ever... At least if we define all of them, how about making strings bit shorter, something like dh-g14-sha256 instead of diffie-hellman-group14-sha256? When you have multiple algorithms tied together (here key exchange method, group, and hash) it is better to avoid full combinatory expansion, and only define those which are known to be used. Especially if we are saying curve25519-sha256 is going to be MUST, I see no reason to define that many MAYs. -- kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 6 13:23:48 2016 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 4586F12B420 for ; Tue, 6 Sep 2016 13:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=denisbider.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 d3VFSuXUdHSt for ; Tue, 6 Sep 2016 13:23:46 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 85C4A12B41C for ; Tue, 6 Sep 2016 13:23:46 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3B38985EB4; Tue, 6 Sep 2016 20:23:46 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id D7C1D85EB3; Tue, 6 Sep 2016 20:23:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id CF54B85EAA for ; Tue, 6 Sep 2016 19:16:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 QhAYnaOeIFOl for ; Tue, 6 Sep 2016 19:16:52 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9D6D184C86 for ; Tue, 6 Sep 2016 19:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=OCbCTn8/oimOMDgZJb8v8Obr/VGpSVr5EJd7AwZxTy8=; b=FBkoxw2+hKsM8XdV8cxcz8sRy1TqV0cYcwPcnm9YwBqJ2hDcAVcmHAr5wTbSIEs5y3sE+I456As4W drA48pPdwOj5sQmCeagNmn/cKVPgMIY/FIQQ7UBkTLui9BjD2NNfU5kaKkhrdJKPnakXifIgkfTSRL W0yQJx5r1UyKYXXy7oWuB8qi7kI615fbRoGYd++mBa0giefwArtukOZdvsb+0KoNBV/rtYfAkAn6h7 0KxpQBVLT2HxZiAvf9k4dsfvAR2Xr4ABlzBT1q4ga70UdK2gtMl1mXRYvTGdE+3kKw6A9zT5rsFeeB G9X7niGbvfXoHNzLBNnuY9KgkSoztJA== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 6 Sep 2016 20:16:42 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Tero Kivinen" , "Mark D. Baushke" Cc: "Daniel Migault" , "Peter Gutmann" , "Watson Ladd" , "Damien Miller" , "IETF Curdle" , "Paul Hoffman" , "Rich Salz" , "IETF SSH" References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> <22478.49300.27045.788996@fireball.acr.fi> In-Reply-To: <22478.49300.27045.788996@fireball.acr.fi> Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Date: Tue, 6 Sep 2016 13:15:31 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011D_01D20840.BE8A27A0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_011D_01D20840.BE8A27A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tero - I agree I would much rather see dh-g14-sha256 than = diffie-hellman-group14-sha256. However, the ship for this has sailed a = long time ago. As far as I know, some of these methods are already = implemented. The benefit of shortening the names is negligible compared = to the likely coordination issues, and it could be argued that the = longer names are more understandable, as well. As far as I know, the cost of making the KEXINIT messages longer is = trivial and probably not even worth mentioning. If SSH wanted to = optimize this to begin with, it would have gone with single-character = names for most algorithms, omit the commas in algorithm lists when not = necessary, etc. The original designers have, in my opinion correctly, = decided that readability trumps conciseness, and that the savings of a = few bytes in a message that=E2=80=99s exchanged once per connection, and = then once per hour or per 1 GB of data, are not worth chasing. >From a performance perspective, the algorithms that involve DH group = exchange are much costlier than negotiating the DH group in the KEXINIT = packet, even if you were to enumerate many more groups than we are = currently proposing. The group exchange methods involve not only sending = two extra messages, which are hundreds of bytes themselves, but require = an entire additional round-trip between the client and the server, = adding noticeable latency to the establishment of the connection, or = completion of key re-exchange. Compared to the group exchange methods, negotiating the DH group in = KEXINIT is downright efficient. And if you don=E2=80=99t want to use all = of the groups, it is fairly straightforward to simply not include them. Our SSH Server is going to include by default only = diffie-hellman-group14-sha256 and diffie-hellman-group15-sha512. It is = also going to be possible to enable diffie-hellman-group16-sha512, but = it=E2=80=99s likely going to be disabled by default because it=E2=80=99s = twice as costly as group 15 and exacerbates a denial of service vector = for busy servers. Our SSH Client is going to include all three of the above methods by = default because it does not have to worry about denial of service. We are not going to support groups higher than 16 at this time, both = because of their cost, and because Windows CNG does not support them. I = nevertheless welcome the definition of those groups, so that it is = straightforward to implement them in case circumstances change so that = this becomes desirable. With respect to Curve25519, I think it=E2=80=99s nice and all, but = it=E2=80=99s probably going to be the first thing broken by a quantum = computer. Anyone concerned with forward secrecy should start using a = hybrid key exchange method that incorporates a quantum-safe algorithm = approximately now. It is that we should be focusing on, I think, instead = of trying to put X25519 everywhere, cast in concrete. It=E2=80=99s going = to bite us. denis From: Tero Kivinen=20 Sent: Tuesday, September 6, 2016 07:11 To: Mark D. Baushke=20 Cc: Daniel Migault ; Peter Gutmann ; Watson Ladd ; Damien Miller ; IETF = Curdle ; Paul Hoffman ; Rich Salz ; denis bider (Bitvise) ; IETF SSH ; = Phillip Hallam-Baker=20 Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Mark D. Baushke writes: > The current draft-ietf-curdle-ssh-kex-sha2-03 draft expires in about a > week, so I will be publishing a new draft before this Friday. Note: I > will not be able to attend the IETF (November 13-18) in South Korea. >=20 > Here is my current sugestions for the DH entries in the table: >=20 > Key Exchange Method Name Reference Note > diffie-hellman-group14-sha256 This Draft SHOULD > diffie-hellman-group15-sha512 This Draft MAY > diffie-hellman-group16-sha512 This Draft SHOULD > diffie-hellman-group17-sha512 This Draft MAY > diffie-hellman-group18-sha512 This Draft MAY >=20 > I do not see any problems with letting these kex method names be = defined > and used by folks that want them. I think it is bad idea to define too many KEX methods. I think there should only be two, one with sha256 one with sha512, i.e., diffie-hellman-group14-sha256 and diffie-hellman-group16-sha512. The reason is that these key exchange methods are negotiated in text. We already have key exchange list in openssh saying something like: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-s= ha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-= sha1 (150 octets), and now when we add to this list new methods: ,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellm= an-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sh= a512 (another 150 octets), it gets to 300 octets, just to negotiate the key exchange methods. And this string is sent in both directions during the negotiation. Also I do not really expect most of them to be used ever... At least if we define all of them, how about making strings bit shorter, something like dh-g14-sha256 instead of diffie-hellman-group14-sha256? When you have multiple algorithms tied together (here key exchange method, group, and hash) it is better to avoid full combinatory expansion, and only define those which are known to be used. Especially if we are saying curve25519-sha256 is going to be MUST, I see no reason to define that many MAYs.=20 --=20 kivinen@iki.fi _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_011D_01D20840.BE8A27A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Tero -
 
I agree I would much rather see dh-g14-sha256 than=20 diffie-hellman-group14-sha256. However, the ship for this has sailed a = long time=20 ago. As far as I know, some of these methods are already implemented. = The=20 benefit of shortening the names is negligible compared to the likely=20 coordination issues, and it could be argued that the longer names are = more=20 understandable, as well.
 
As far as I know, the cost of making the KEXINIT messages longer is = trivial=20 and probably not even worth mentioning. If SSH wanted to optimize this = to begin=20 with, it would have gone with single-character names for most = algorithms, omit=20 the commas in algorithm lists when not necessary, etc. The original = designers=20 have, in my opinion correctly, decided that readability trumps = conciseness, and=20 that the savings of a few bytes in a message that=E2=80=99s exchanged = once per=20 connection, and then once per hour or per 1 GB of data, are not worth=20 chasing.
 
From a performance perspective, the algorithms that involve DH = group=20 exchange are much costlier than negotiating the DH group in the KEXINIT = packet,=20 even if you were to enumerate many more groups than we are currently = proposing.=20 The group exchange methods involve not only sending two extra messages, = which=20 are hundreds of bytes themselves, but require an entire additional = round-trip=20 between the client and the server, adding noticeable latency to the=20 establishment of the connection, or completion of key re-exchange.
 
Compared to the group exchange methods, negotiating the DH group in = KEXINIT=20 is downright efficient. And if you don=E2=80=99t want to use all of the = groups, it is=20 fairly straightforward to simply not include them.
 
Our SSH Server is going to include by default only=20 diffie-hellman-group14-sha256 and diffie-hellman-group15-sha512. It is = also=20 going to be possible to enable diffie-hellman-group16-sha512, but = it=E2=80=99s likely=20 going to be disabled by default because it=E2=80=99s twice as costly as = group 15 and=20 exacerbates a denial of service vector for busy servers.
 
Our SSH Client is going to include all three of the above methods = by=20 default because it does not have to worry about denial of service.
 
We are not going to support groups higher than 16 at this time, = both=20 because of their cost, and because Windows CNG does not support them. I=20 nevertheless welcome the definition of those groups, so that it is=20 straightforward to implement them in case circumstances change so that = this=20 becomes desirable.
 
With respect to Curve25519, I think it=E2=80=99s nice and all, but = it=E2=80=99s probably=20 going to be the first thing broken by a quantum computer. Anyone = concerned with=20 forward secrecy should start using a hybrid key exchange method that=20 incorporates a quantum-safe algorithm approximately now. It is that we = should be=20 focusing on, I think, instead of trying to put X25519 everywhere, cast = in=20 concrete. It=E2=80=99s going to bite us.
 
denis
 
 
Sent: Tuesday, September 6, 2016 07:11
Cc: Daniel Migault ; Peter=20 Gutmann ; Watson Ladd ; Damien Miller ; IETF Curdle ; Paul Hoffman ; Rich Salz ; denis bider (Bitvise) ; IETF = SSH ; Phillip = Hallam-Baker=20
Subject: Re: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 
Mark=20 D. Baushke writes:
> The current draft-ietf-curdle-ssh-kex-sha2-03 = draft=20 expires in about a
> week, so I will be publishing a new draft = before this=20 Friday. Note: I
> will not be able to attend the IETF (November = 13-18) in=20 South Korea.
>
> Here is my current sugestions for the DH = entries=20 in the table:
>
> Key Exchange Method=20 Name           &nb= sp; =20 Reference     Note
>=20 diffie-hellman-group14-sha256       &n= bsp;=20 This Draft    SHOULD
>=20 diffie-hellman-group15-sha512       &n= bsp;=20 This Draft    MAY
>=20 diffie-hellman-group16-sha512       &n= bsp;=20 This Draft    SHOULD
>=20 diffie-hellman-group17-sha512       &n= bsp;=20 This Draft    MAY
>=20 diffie-hellman-group18-sha512       &n= bsp;=20 This Draft    MAY
>
> I do not see any = problems with=20 letting these kex method names be defined
> and used by folks that = want=20 them.

I think it is bad idea to define too many KEX methods. I = think=20 there
should only be two, one with sha256 one with sha512,=20 i.e.,
diffie-hellman-group14-sha256 and=20 diffie-hellman-group16-sha512.

The reason is that these key = exchange=20 methods are negotiated in text.
We already have key exchange list in = openssh=20 saying something=20 like:

curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-ni= stp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hel= lman-group14-sha1

(150=20 octets), and now when we add to this list new=20 methods:

,diffie-hellman-group14-sha256,diffie-hellman-group15-sha= 512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-he= llman-group18-sha512

(another=20 150 octets), it gets to 300 octets, just to negotiate the = key
exchange=20 methods. And this string is sent in both directions during
the=20 negotiation.

Also I do not really expect most of them to be used=20 ever...

At least if we define all of them, how about making = strings=20 bit
shorter, something like dh-g14-sha256 instead=20 of
diffie-hellman-group14-sha256?

When you have multiple = algorithms=20 tied together (here key exchange
method, group, and hash) it is = better to=20 avoid full combinatory
expansion, and only define those which are = known to be=20 used.

Especially if we are saying curve25519-sha256 is going to = be MUST,=20 I
see no reason to define that many MAYs.
--=20
kivinen@iki.fi

_______________________________________________=
Curdle=20 mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_011D_01D20840.BE8A27A0-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 6 15:54:33 2016 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 1148912B411 for ; Tue, 6 Sep 2016 15:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 JPlZ5zKbUHsI for ; Tue, 6 Sep 2016 15:54:32 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 9CF5512B03A for ; Tue, 6 Sep 2016 15:54:31 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 64A6285EC3; Tue, 6 Sep 2016 22:54:30 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EC30F85EC1 for ; Tue, 6 Sep 2016 22:54:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 16jHrxC5a6fL for ; Tue, 6 Sep 2016 22:54:24 +0000 (UTC) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0119.outbound.protection.outlook.com [104.47.36.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 51F0585EBF for ; Tue, 6 Sep 2016 22:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qqb5WQbl5l3RmUc39LNSLpZ6ky9sZzh/2sKpD5St1dY=; b=Cu9dxFVr0am0xG6NobvzsRdFkPe+MdNz4GTfMaFL7bD6CE7DsywSM+zYANoXLsXGu0vtHd6H9BzAc1sFsVeON77N9/prxBoIiEzvaieCVrfkG5GbEhwjtZgD1IDAwZgvFwRCJDqKtIaaMU7DTpaRYyAoU/GodjyqLbBOS4phUio= Received: from SN1PR05CA0012.namprd05.prod.outlook.com (10.163.68.150) by DM2PR0501MB1199.namprd05.prod.outlook.com (10.160.245.24) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Tue, 6 Sep 2016 19:20:43 +0000 Received: from BL2FFO11FD046.protection.gbl (2a01:111:f400:7c09::134) by SN1PR05CA0012.outlook.office365.com (2a01:111:e400:5197::22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.3 via Frontend Transport; Tue, 6 Sep 2016 19:20:42 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD046.mail.protection.outlook.com (10.173.161.208) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Tue, 6 Sep 2016 19:20:42 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Sep 2016 12:19:41 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u86JJeOx023370; Tue, 6 Sep 2016 12:19:40 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 0349C1141B; Tue, 6 Sep 2016 12:19:39 -0700 (PDT) To: Tero Kivinen CC: Peter Gutmann , "denis bider (Bitvise)" , Damien Miller , Daniel Migault , IETF SSH , Watson Ladd , IETF Curdle , Paul Hoffman , Rich Salz , Phillip Hallam-Baker Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: <22478.49300.27045.788996@fireball.acr.fi> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> <22478.49300.27045.788996@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Tue, 06 Sep 2016 16:11:48 +0300." From: "Mark D. Baushke" Date: Tue, 6 Sep 2016 12:19:38 -0700 Message-ID: <78699.1473189578@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(51444003)(4326007)(230783001)(2950100001)(7126002)(5660300001)(2810700001)(53416004)(106466001)(77096005)(356003)(81166006)(97736004)(189998001)(76506005)(626004)(8676002)(81156014)(8936002)(54356999)(19580395003)(7696003)(305945005)(7416002)(47776003)(93886004)(76176999)(69596002)(48376002)(50466002)(92566002)(68736007)(105596002)(11100500001)(586003)(19580405001)(561944003)(50986999)(2906002)(110136002)(87936001)(117636001)(86362001)(5003940100001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1199;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD046;1:+yPO8Na13XIC82/TMX9iWmwiEc35J4wsodv6x22UIYN8FKEHfdo27ly3in8kGWnBg2wIN6Wtm4lbsZqpMtR6kFrAw1BC9g4lk2GnCvBojl0ifiMI+RqNsIdDXdtCIi/WjUA2Y7CoTTiuJMkoxKK8LoT8AntVG1qIyM4tbvf4FlTnxuAX5IfewYNvNtbZDTgGtpyw3ED8HebvLsjrgRx1fdqx6PpLe5dXzdQ7JpWY//cbPA1WKDJAXTv4QSlTUv/VrBVnlyz4fZu+kkG5S3IdxsC8wQNBMiSTe2mS73BIC00MePrd7B9JmINlMdbvJacoTZVkBupS1fXxpeY2UQw913jvv/5EWjZvzoCgXmkk0ftuBxmuogor5L1em9UIvCa415dSLPRtZO/H8RvavktJLQaitIOqHYnpohHWGxq+PoHkp5+JzYXvEkmcfudFD7+KPLKM5oZkyKcPM52g0XjXEY716RNMvzaISkJky2dSgW4LdO+2VHf9NrDd0kLSa7mXHkFmyuItJmSwtwk9G4h3LgEciMJHWUvfZSyTJ4bQBPukZfBQPmaIidd5/icrIWOVE0fhxW9NgQJDScHRHxd82g== X-MS-Office365-Filtering-Correlation-Id: c79d44d7-cf94-45b6-f760-08d3d68ae528 X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;2:T0T+p/dSLookdsJ1v57eVmA0n/acSWRr7yneacnOv0pZnOsCJyOsbmS3wU4zXganV6vbHxsAsgJ3tq5+AiIOrjjKC7BhOxArn+G7dVm/AWN4QsHI62yBOdET+CDV9u2hmUXBDougJHDsUCtcjpDLzu7yRWldMjntElij6ZeA/g/c+1KlASTOM6ZDC4QhhhtQ;3:QwyCWpbOxrkWufPGrEp9aVjzxRT6G0w4K9arpMTdXor03O+qYjRUspaMIT8tklEwrCpKvZeNyKUKvQDG1wPDhcZlWA2R3/NMMFRqVvIeP4S1uqZonbF8E4VR+LLc8hQB0KPDumdEOIwS2tFawLOSpRS9ty/jz3QP3pFRcJxtvQNYWeZGvwQV8h1jeR6wSE+U03Z3CZKsNj4uuhR+YtB5b3wkh8jwV2unwjZ+nsvjFYA=;25:ft35sY00lQopVCMr3MWg497CK5gOA5ibiJ5/mdS3EFA0EN4VyOEB+kOnwzVoohcwblIbOiMVmR9m7Rlmr2FTNKc4/j6x6jT7InTWF9Lgf1abDPUwH4ke6ittkv5B6049UUlOdIf+On0gj4hb80lIZVGceXl0rzLZcIXnzjoP+WZZxPPHIKNpk0DOz2IKR0ocX4vOFC9a02KUlv4ob4KWpcLJPch2mtPDnGOZpYrr6UqBB4uidyPnsmZpQlRz5nE5oBot+hfixPu6FJLz9FJBjOUhfJtQvSjbzZZuzqV9zZbmY0jH9nnUzPDp2G0jVIFW/IrNA5fTmAnIf3xMx0vLy9MG7BE1630AvbEaaIDwRG0hV7eVF5HE2es3sYHfaOt/JnYUiRjH4bZqZj2L+OF3buqYROqEdY34SeBlXEqtKJQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1199; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;31:cvodk5DGDjamYstMtF4l5kAijWgcMlWVOorFYwXbc3lxj/RRJS1UcJ/KBz0er7o1uGVXmrhb+h64z6WDp1NF0e6FfTcMfVKeHumaGg6+uEVqY23bFowcE9EWuMtsniwYJb5Bch+9hyVPJSdlU0cLU6NZlJMtDefdc/UUoNFariHK5PcSwkw/pF6h0yAUz4cIlhEihEQAW8vs7jnhcaOf/hmX99gTIwEkbyMiF0OMdE8=;20:LTHmVAR4i8PfwISESWx1Cnkbu9DKi/1VN1DqTxr5ZgdMbrMcUN+nWHDnyaiFadPS6vnSZY8+BBDn4p2HqU8Ygu631BSqrYYmMewjhKyZCYamJRnOmBsUTZFaqD4nWeCiv2yxCu/7Pn1pFRoUsTQUanpvtTCaQLWOez7QMlfXVDGdN0u0DuGWENdXvBpK+3y8LQ6xe6Yzac3XO5W3cNH/5HrKqVxdbju4MTtS6SR4+X3v7J9zg/RrL5U/PlAfNUcltDv75ho1j8hIJN4ANoBU6aL5+I8n/wUZG8XnQxQNpz7Wav4BWkGozy+Mhv64RKTBLCmRex7pg5pko+UcvRMTFj2M1bs4knKtz2JGLHWBhBFK6eGSlY8z5eFgJmpG9k/C4rrel/1iAa/cLSJ5xS0+2Mcg2SGfSgs/uNVJhudGl7YRr8XyjSwcOVDnpFGdAL3cUNANLeVCulZ7i38bxKWSNM45lKAeZrWqOvhGcoJ74B/B/2JBM0zWB3CI7HCpN+Z+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13017025)(8121501046)(5005006)(13015025)(13024025)(13023025)(13018025)(3002001)(10201501046)(6055026);SRVR:DM2PR0501MB1199;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1199; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;4:MqrXs+3fwf7Y424xDDQLiDB/65xKPsgHdUYBIhFfcXfNBucrVFyiZz8adJjMVGgGpiThWug3MraPJiUZV098VhOomfDg/obIUUgpfysZ/B+Hsy8sBl/runMnFDfTaHZY4IilcVQwcIq1AehPKncBE68Bja8bzwiJ8/wvl9OcPYk0PqOhQy0awZGEzFMQSt5sRftIRfTi7aafkO6LjNfHwN4WAqWbcEHTGE+/cDmo6945OaywkhKCLNSv8qzBpHr1sMBUrR+ir0yAwhYcKZZKlJd8j9poeOo8+RzQrzR38bQxBcfCODSKbeDGVC0mS0jyE7o2H/ot9Fz006UBTxM0MRuo6Lla093uJugx4Z6RO84Gz0/k+PU9gKDixQL61L43t56wxmBOTKxuyAKKwv8kP/bS2Z1ELDMMNZfMuSLbgiBDxPUhVcGKBt2JKncwRtNMVkMSYJltcFCvMv1mHNj2uSOL/3qv//ALaXcwaYzW5XyMCzh+p8kwjKIcVo4CIUbW X-Forefront-PRVS: 0057EE387C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR0501MB1199;23:Iz6EOpMVVQBfMt1OGitgLbJV3OP+PbIhA5eRob8?= =?us-ascii?Q?1+3U9xn6BEwcD+KoC7UP65h1lrpIn9GZYEFUExr2whuI6w651x2aP/YXhhID?= =?us-ascii?Q?m5nk+hY1i3ykWD4V7Ditx6jcUwMUZXztLb3XIVjbGmC6shzvgSRmbh3etHeY?= =?us-ascii?Q?LIUxcOdwq8Sg0azWO5pVfB6xxBVo2srqsl1Nm+ZKIlFGWDjHTY1MbtfKXIOt?= =?us-ascii?Q?9+MinzCCnHL5To7MyLqq8gzkRUhw1bc56o+tmhzcxS0DgwZ1wR/4imHFWxw4?= =?us-ascii?Q?hZaxnU1AwzrWpw6uST4ROQz1bwhySqiT2GmpT3ldAbwIOQBU7IA3YK7pGSTZ?= =?us-ascii?Q?J0XxHV6l1u6b+Zfkxg24sP0W4N2tqvcDRTSZW22ObuSAL/a/EtMZZ7msnpHa?= =?us-ascii?Q?wvHLBa7cwYQ9zpHnLDRyWvqM9QfRjbMf8TM8G+M/fCT9NXmGmGolyOzAtAWl?= =?us-ascii?Q?ORurZnrbxKFXXef/n42VAx4N84+hHY85GCTPsou5ALcNoXEO+QLzJX+rDSrE?= =?us-ascii?Q?Vg7k+pjhhPYyQwvECec8aH8xOUMQCN+z3/mFoRLzBw92958rpWmfjHgYISiL?= =?us-ascii?Q?1sp+3T2ohE5HTYQ3d2uqpJAB3KkyxHh25aNmWALb1CT+yFMkFmh9dqHm7Ubk?= =?us-ascii?Q?YzyotMeVJlzDXVt+NYuYnfsw6bdHGXU+VylvxR86pTs7SvFf+tNpZX6eraHB?= =?us-ascii?Q?OZwq6jPLtBhJXJYl4ODUxV1/lPdou7WFcU0yvwA96RUKfyaDunLH0PAJjuP/?= =?us-ascii?Q?9WSItjdJXw+uUUjwi8fDDoPHQYaExlpO/qVh3Brn5SE+CYKwy7QkgACrqPry?= =?us-ascii?Q?2HgMZbKAsdrKjMdKj2VMDGfA00mj7ri0DIQPrAlsmTkasrkqe4hUDbuTx+Fm?= =?us-ascii?Q?B6JBEq2XDvCE75CFW03aoUaq5S6556yAo9ymI0BWiUnUlWeFmmPU7+qhNusl?= =?us-ascii?Q?kzoj623hBB/MEC9Wrkip2TIbGtBlqDp71nNYdPqdq47LQ5XgfEHNG6ZZHhc7?= =?us-ascii?Q?IwMoLZ/P4DTgWWhv5a4QWJ6OuFHAplnIs7ZZKIbv0/MigOGU4JB6m0VyA9Kg?= =?us-ascii?Q?/MfefRuKBMRhW+IW8B/VCfo7ajsRtP0BDgHR0EAyRF0yRYjK+SLTxLYS4cRP?= =?us-ascii?Q?7Gngabbdm7RL0RfGswYSUzQMec5LhLnznysM+DozbuF1Q6+NnXOEuATz4AlZ?= =?us-ascii?Q?YuCVtHNaTnsnbvSWmkZdS6n2x5uoricRcrggL?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;6:+ajC0qdyXQFqW0deoL8YYOiXXRUFhFi9Q+g32D9lj6faLfcgd1VgExOaBUW3DlQIvq6gUeKGKTUsJ84Ikz+JaeCoN0+vnkB0/8NkIadishMfw7Olq3XVK7Fdv3ISO8o3v9IsELSZTP7rXyESxLHItuVVcFRGArKHDha/t3AY/l1OOsvBfYQNH8kI0pXkmP45+viA9ok6KglOY5pzcsPNFaLxmRQCufNJdl2rpnYdsasv18WMdR+qbHeU4YSbwbspDc+S0GzPqXHTqTAg8dpIZpxuff71K+Px7vaDlI/C+J7LGQsox5A22xLW8CPCLXLoIfOsA7samtnCJSBkW/Jhyg==;5:M5fVNeqm6vabMjOWBT3uzpmLJlM1WYeAO+xXQba+hvMXQKgxdcpPjrgFi88s0U/KmJRLl9WX4zy3sy8hwvcJlXsi/LeJ5w3Tsf94ibm111ERyq3ogWJ+KWN0I4ChdUdel1MFtdu2nq5GPwIAh3m7WA==;24:c7y+cVTT1IrXNq+SKWpynMN3mDOjrh6VW4w2b6hINdrwm4MfusRDnaW8Fx1mVCuYQ6NWfxI7JSmu/Nvfylx1N/CvEXphY4fRkL/vuxhak7E=;7:GeI5aRuJ4dtF2ezoGKMOZ35Sh/M3DsqQqID1KkEmyVg1I3vuzbTWqcvUnQtoUQyFTy3EFB0F8QuvAajk5LLzuxu6AK7sjLtOOLtXES35BSNxmZsDg8BN1maVTTePJyTzcqFPRHgsLDR2QtguQHS5Uwukh07ZONvVjhytV1ccsIszLiH232M1mca6Kqb6dPQHAaddzv42a4yhRnt9/F34v98JN2xfhbKtVaTcQUOzuJL1etpBs774pOeYi0ZOGWiY SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Sep 2016 19:20:42.4282 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1199 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Tero Kivinen writes: > Mark D. Baushke writes: ...elided... > > I do not see any problems with letting these kex method names be defined > > and used by folks that want them. > > I think it is bad idea to define too many KEX methods. > > I think there should only be two, one with sha256 one with sha512, > i.e., diffie-hellman-group14-sha256 and diffie-hellman-group16-sha512. You would be implementing the SHOULD MODP groups in this case. This seems like a reasonable configuration choice. If possible, I would hope you could also support curve25519-sha256, given it seems desirable for it to be a MUST kex. > The reason is that these key exchange methods are negotiated in text. > We already have key exchange list in openssh saying something like: > > curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 > > (150 octets), and now when we add to this list new methods: Yes, but this draft RFC is moving most of those to MAY and some to SHOULD NOT. I would expect that after this RFC is published, a number of implementation of the default kex proposals would only contain this list: curve25519-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 which is the MUST and SHOULD entries which is only 143 octets. > ,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512 > > (another 150 octets), it gets to 300 octets, just to negotiate the key > exchange methods. And this string is sent in both directions during > the negotiation. Yes. Even if everyone were to implement all of the current kex methods and have a proposal for each of them, is this a sufficient problem for an implementation to need to save a sixteen bytes per algorithm? If there support from the implementors for this change, I will ammend my draft. > Also I do not really expect most of them to be used ever... The hope is that there is flexibility in the implementations to allow us to more quicly discard 'weak' entries and adopt 'strong' entries as we move forward. > At least if we define all of them, how about making strings bit > shorter, something like dh-g14-sha256 instead of > diffie-hellman-group14-sha256? I think that the implementors need to provide their inputs on what strings should represent the algorithms to be used. > When you have multiple algorithms tied together (here key exchange > method, group, and hash) it is better to avoid full combinatory > expansion, and only define those which are known to be used. Isn't that a chicken and egg problem? None of these new kex names are currently being used. I would like to have at least one kex that uses sha512 given that some cryptographic experts in the US government seem to think that sha256 is not good enough for top secret. I don't know if they are ultra paranoid or not, but it seems prudent to err on the side of being a bit paranoid if it is not too expensive for the uses involved. > Especially if we are saying curve25519-sha256 is going to be MUST, I > see no reason to define that many MAYs. There are a lot of different stake-holders in this standard. I do not pretend to be able to make the business trade-offs for everyone. The primary goal of this RFC is to demote a number of weak key exchanges and to promote the curve25519-sha256 kex. If there are enough implementations that are able to move away from MODP groups, then perhaps all of them could be deprecated. However, the diversity of the math seems to be a compelling reason to have DH, ECDH, and EdDH methods in place. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Sep 10 09:57:36 2016 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 2DBEF12B097 for ; Sat, 10 Sep 2016 09:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 ErC-Hyk8I_XS for ; Sat, 10 Sep 2016 09:57:34 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 3EA4112B061 for ; Sat, 10 Sep 2016 09:57:33 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 13B7A85F04; Sat, 10 Sep 2016 16:57:27 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B8FB285F03; Sat, 10 Sep 2016 16:57:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8817185ED8 for ; Wed, 7 Sep 2016 10:43:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id z6HH3CWkDILU for ; Wed, 7 Sep 2016 10:43:51 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E415885ED0 for ; Wed, 7 Sep 2016 10:43:45 +0000 (UTC) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u87AgoTo014756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Sep 2016 13:42:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u87AgkEc020705; Wed, 7 Sep 2016 13:42:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22479.61222.166373.218970@fireball.acr.fi> Date: Wed, 7 Sep 2016 13:42:46 +0300 From: Tero Kivinen To: "denis bider \(Bitvise\)" Cc: "Mark D. Baushke" , "Daniel Migault" , "Peter Gutmann" , "Watson Ladd" , "Damien Miller" , "IETF Curdle" , "Paul Hoffman" , "Rich Salz" , "IETF SSH" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 In-Reply-To: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> <28415.1472767053@eng-mail01.juniper.net> <9A043F3CF02CD34C8E74AC1594475C73F4D0C59E@uxcn10-5.UoA.auckland.ac.nz> <47469.1473112604@eng-mail01.juniper.net> <22478.49300.27045.788996@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 23 min X-Total-Time: 24 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider \(Bitvise\) writes: > I agree I would much rather see dh-g14-sha256 than > diffie-hellman-group14-sha256. However, the ship for this has sailed = a long > time ago. As far as I know, some of these methods are already impleme= nted. The > benefit of shortening the names is negligible compared to the likely > coordination issues, and it could be argued that the longer names are= more > understandable, as well. If they follow the rules set for the identifiers for the secure shell, they should not use names without domain name before "IETF CONSENSUS". If they do that is their problem. We cannot make old names to use shorter names, but we can make the new allocations to use shorter names. If someone implements things before it is out as RFC, they should be able to update their implementations too when the RFCs come out.=20 > As far as I know, the cost of making the KEXINIT messages longer is t= rivial > and probably not even worth mentioning. If SSH wanted to optimize thi= s to > begin with, it would have gone with single-character names for most > algorithms, omit the commas in algorithm lists when not necessary, et= c. The > original designers have, in my opinion correctly, decided that readab= ility > trumps conciseness, and that the savings of a few bytes in a message = that=E2=80=99s > exchanged once per connection, and then once per hour or per 1 GB of = data, are > not worth chasing. The idea was that there is only one or two key exchange methods at times, there was never supposed to be dozens of them. The encryption algorithms, mac algorithms etc used much shorter names. And I do remember people complaing that they do not want ot use @ssh.com etc prefix, as it makes the names longer... > From a performance perspective, the algorithms that involve DH group = exchange > are much costlier than negotiating the DH group in the KEXINIT packet= , even if > you were to enumerate many more groups than we are currently proposin= g. The > group exchange methods involve not only sending two extra messages, w= hich are > hundreds of bytes themselves, but require an entire additional round-= trip > between the client and the server, adding noticeable latency to the > establishment of the connection, or completion of key re-exchange. There is no need to really negotiate DH group in the KEXINIT packet, you need to agree on common one. For example IKEv2 uses a method, where the initiator proposes all groups it will allow, and picks one of them and sends KE payload for it. The responder will then either accept the selected group if it acceptable for him. If it is not acceptable for responder, it will send notification back, saying that your group was not acceptable, but this group is, so then the initiator retries with the same list of allowed groups, but different group in KE payload. This allows agreement of common group in case there is one, and also most of the times both ends have same group allowed, thus the initial selection is suitable for both ends too. This is how the DH group agreement should have been done in secure shell too, but unfortunately it was not done in this way, and now is too late to change that. > Compared to the group exchange methods, negotiating the DH group in > KEXINIT is downright efficient. And if you don=E2=80=99t want to use = all of > the groups, it is fairly straightforward to simply not include them. If i remember right the secure shell DH group negotation sends the full group information, and I think that is bad idea. Verifying the group takes long time (full primatlity checks etc), thus you should not accept random groups sent by other end. On the other hand if you always require both ends to configure same set of groups to both ends before they can be used, then you might as well give names for them. Yes, I agree that using predefined groups is much better than using groups sent inline the exchange.=20 > Our SSH Server is going to include by default only > diffie-hellman-group14-sha256 and diffie-hellman-group15-sha512. It i= s also > going to be possible to enable diffie-hellman-group16-sha512, but it=E2= =80=99s likely > going to be disabled by default because it=E2=80=99s twice as costly = as group 15 and > exacerbates a denial of service vector for busy servers. Ok, so you would like to define three. That would still be ok, and it is better than the five there is now, but I still think two should be enough. > With respect to Curve25519, I think it=E2=80=99s nice and all, but it= =E2=80=99s > probably going to be the first thing broken by a quantum computer. > Anyone concerned with forward secrecy should start using a hybrid > key exchange method that incorporates a quantum-safe algorithm > approximately now. It is that we should be focusing on, I think, > instead of trying to put X25519 everywhere, cast in concrete. It=E2=80= =99s > going to bite us. We are working on that in the IPsecME for the ESP. I.e., a way to make ESP quantum computer resistant. I.e., the main goal is to make so that even if you store all ESP traffic now, you cannot decrypt them when you get the quantum computers, unless you also know the shared secret between hosts. Something like that might also work with secure shell, but situation is bit different there, as in IKE/ESP both the client and server will have connection related configuration, thus having one more pairwise configurable thing there is not that hard, while in secure shell it might be. --=20 kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Sep 10 09:57:56 2016 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 E647A12B04D for ; Sat, 10 Sep 2016 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 HS9lMj4BrIb2 for ; Sat, 10 Sep 2016 09:57:54 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 6263112B044 for ; Sat, 10 Sep 2016 09:57:54 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 20A8C85F06; Sat, 10 Sep 2016 16:57:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id C7D0485F05; Sat, 10 Sep 2016 16:57:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 15C9285E95 for ; Sat, 10 Sep 2016 06:36:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 mdGk9vnt9n-v for ; Sat, 10 Sep 2016 06:36:56 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 214D785E61 for ; Sat, 10 Sep 2016 06:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type; bh=JXm7zUdwxFqXWlqsw8dmOETkG4kU7YfHm6xsAOlf6oo=; b=c4CnfbLeHpD7AuUh+k94B3nRzYZoiUY7gSxqti1606PNlRANEb2G7mCzSMkVGLRI6XSp9DaofVzyy SwcP5VgE9MNRBAYIRrLZhUnalhyqy69mlLnhxJTkaCaCMiNAQu1AQuNaeBnUeh012Yw5Tiw/q0AbG7 jFWqwSqga47dO/urvnTC2plz/ZEHvN5OCL0+gg372lm9Wmvy/Ckb2Vl1ho6G/OZldB7Y3RfFLDO0Rb KJUUkhfQnojQsfJrclBrdRO5mtaiTPD85mHKcE28+tstl5G+7uoc7TGlrPUNdnEl49VAEMCT6vv5js HDFlYFwohbyXrN/GDpNKPYyOxbT6erQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 10 Sep 2016 07:36:34 +0100 Message-ID: <52268E1E6876438094A2D6E779F8145C@Khan> From: "denis bider \(Bitvise\)" To: "Curdle" Cc: Subject: [SSH] GSS key exchange methods Date: Sat, 10 Sep 2016 00:35:55 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01D20AFB.4AA8A100" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_012A_01D20AFB.4AA8A100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Curdle, and the old SSH list: I forward parts of a correspondence with Mike discussing the need to = address GSSAPI key exchange methods in the ssh-kex-sha2 draft: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-04 - denis: "RFC 4462 defines the following key exchange methods, which our SSH = Client and Server implement. I am aware also of other implementations by = other vendors, and we hear from users who use them: https://tools.ietf.org/html/rfc4462 The exchange methods parallel the DH key exchange methods, and are = currently: gss-group1-sha1-* gss-group14-sha1-* gss-gex-sha1-* The current version of the ssh-kex-sha2 draft mentions these, but only = to deprecate gss-gex-sha1-* and gss-group1-sha1-*. The draft allows = gss-group14-sha1-* as a MAY, but does not define any new versions of = these methods to parallel the new DH methods. These key exchange methods serve a valuable role in environments where = it is possible to authenticate using Kerberos, which is in Unix realms = and Windows domains. The existing trust relationship between the client = and the server can be used in this case, and allows for host = authentication without having to set up or verify a host key on the = client. This substantially improves security and usability in these = environments, since lack of proper host key verification procedures is a = big security risk, but their presence is a big pain point for = administration. These key exchange methods avoid that problem in = environments that already have an existing trust network to begin with." - Mike: "You make a really good point, I did leave out the GSS-API updates and = only deprecated the -sha1-* entries. I suspect that the same reasons we defined groups 15, 16, 17, and 18 to = use sha512 would hold for gss-group* kex methods. so, adding: Key Exchange Method Name Reference Note gss-group14-sha256-* This Draft MAY gss-group15-sha512-* This Draft MAY gss-group16-sha512-* This Draft MAY gss-group17-sha512-* This Draft MAY gss-group18-sha512-* This Draft MAY would make sense." -snip- My proposal also included a suggestion to update the gss-gex- method. = Since it seems unlikely that the GSS methods will be implemented by = resource-constrained devices - in order to use this, a device would have = to be part of a Unix realm or a Windows domain - I suggested = gss-gex-sha512-* to provide a hash that meets the security level of any = DH group. Mike is currently unsure about updating gss-gex-. I don't feel strongly = about this, because the DH group exchange methods are a bit of a can of = worms (FIPS requires group validation that fails with deployed ephemeral = groups). The main priority is that GSS methods serve a unique function, = and it would provide value to maintain them. For the same reasons we define the DH groups, I think it makes sense to = define the above groups. However, if I needed to pick only one, my = priority would be gss-group15-sha512. This is for the same reasons I = prefer diffie-hellman-group15-sha512. It meets all security = recommendations, both in terms of DH group size and hash size, and it is = 2x faster than group 16, which has performance characteristics that = begin to close the gap between denial of service and normal rate of = connections on busy servers. Does anyone else second these suggestions? Defining this will not affect servers and clients that do not have a use = for key exchange and host authentication using Kerberos. Only folks who = want to use this will be affected. I am aware of other implementations of these key exchange methods = besides ours, including patches for popular open source software. = I=E2=80=99m not sure if PuTTY implements them; I think it might just = implement the user authentication method gssapi-with-mic. For the people = who do implement this, I=E2=80=99m not sure if they have representation = or awareness of this list. denis ------=_NextPart_000_012A_01D20AFB.4AA8A100 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello Curdle, and the old SSH list:
 
I forward parts of a correspondence with Mike discussing the need = to=20 address GSSAPI key exchange methods in the ssh-kex-sha2 draft:
 
ht= tps://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-04
 
- denis:
 
"RFC 4462 defines the following key exchange methods, which our SSH = Client=20 and Server implement. I am aware also of other implementations by other = vendors,=20 and we hear from users who use them:
 
https://tools.ietf.org/html/= rfc4462
 
The exchange methods parallel the DH key exchange methods, and are=20 currently:
 
gss-group1-sha1-*
gss-group14-sha1-*
gss-gex-sha1-*
 
The current version of the ssh-kex-sha2 draft mentions these, but = only to=20 deprecate gss-gex-sha1-* and gss-group1-sha1-*. The draft allows=20 gss-group14-sha1-* as a MAY, but does not define any new versions of = these=20 methods to parallel the new DH methods.
 
These key exchange methods serve a valuable role in environments = where it=20 is possible to authenticate using Kerberos, which is in Unix realms and = Windows=20 domains. The existing trust relationship between the client and the = server can=20 be used in this case, and allows for host authentication without having = to set=20 up or verify a host key on the client. This substantially improves = security and=20 usability in these environments, since lack of proper host key = verification=20 procedures is a big security risk, but their presence is a big pain = point for=20 administration. These key exchange methods avoid that problem in = environments=20 that already have an existing trust network to begin with."
 
- Mike:
 
"You make a really good point, I did leave out the GSS-API updates = and only=20 deprecated the -sha1-* entries.
 
I suspect that the same reasons we defined groups 15, 16, 17, and = 18 to use=20 sha512 would hold for gss-group* kex methods. so, adding:
 
Key Exchange Method=20 Name           &nb= sp; =20 Reference     Note
gss-group14-sha256-*        =          =20 This Draft    MAY
gss-group15-sha512-*        =          =20 This Draft    MAY
gss-group16-sha512-*        =          =20 This Draft    MAY
gss-group17-sha512-*        =          =20 This Draft    MAY
gss-group18-sha512-*        =          =20 This Draft    MAY
 
would make sense."
 
-snip-
 
My proposal also included a suggestion to update the gss-gex- = method. Since=20 it seems unlikely that the GSS methods will be implemented by=20 resource-constrained devices - in order to use this, a device would have = to be=20 part of a Unix realm or a Windows domain - I suggested gss-gex-sha512-* = to=20 provide a hash that meets the security level of any DH group.
 
Mike is currently unsure about updating gss-gex-. I don't feel = strongly=20 about this, because the DH group exchange methods are a bit of a can of = worms=20 (FIPS requires group validation that fails with deployed ephemeral = groups). The=20 main priority is that GSS methods serve a unique function, and it would = provide=20 value to maintain them.
 
For the same reasons we define the DH groups, I think it makes = sense to=20 define the above groups. However, if I needed to pick only one, my = priority=20 would be gss-group15-sha512. This is for the same reasons I prefer=20 diffie-hellman-group15-sha512. It meets all security recommendations, = both in=20 terms of DH group size and hash size, and it is 2x faster than group 16, = which=20 has performance characteristics that begin to close the gap between = denial of=20 service and normal rate of connections on busy servers.
 
Does anyone else second these suggestions?
 
Defining this will not affect servers and clients that do not have = a use=20 for key exchange and host authentication using Kerberos. Only folks who = want to=20 use this will be affected.
 
I am aware of other implementations of these key exchange methods = besides=20 ours, including patches for popular open source software. I=E2=80=99m = not sure if PuTTY=20 implements them; I think it might just implement the user authentication = method=20 gssapi-with-mic. For the people who do implement this, I=E2=80=99m not = sure if they have=20 representation or awareness of this list.
 
denis
 
------=_NextPart_000_012A_01D20AFB.4AA8A100-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sat Sep 10 23:12:34 2016 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 31FCF12B030 for ; Sat, 10 Sep 2016 23:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 LhOM8BPa7xOb for ; Sat, 10 Sep 2016 23:12:33 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 E5022128B38 for ; Sat, 10 Sep 2016 23:12:32 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 162D985E70; Sun, 11 Sep 2016 06:12:32 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B29FB84CEC; Sun, 11 Sep 2016 06:12:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7CAB685F03 for ; Sat, 10 Sep 2016 17:48:25 +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 EnBwEHPgSVu1 for ; Sat, 10 Sep 2016 17:48:24 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 661FB85DFE for ; Sat, 10 Sep 2016 17:48:23 +0000 (UTC) X-AuditID: 12074425-56bff70000000cd6-3e-57d447606d99 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E2.D8.03286.06744D75; Sat, 10 Sep 2016 13:48:16 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u8AHmFJN023548; Sat, 10 Sep 2016 13:48:15 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8AHmBYC028157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Sep 2016 13:48:14 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8AHmBSl028014; Sat, 10 Sep 2016 13:48:11 -0400 (EDT) Date: Sat, 10 Sep 2016 13:48:10 -0400 (EDT) From: Benjamin Kaduk To: "denis bider (Bitvise)" cc: Curdle , ietf-ssh@netbsd.org, gss-openssh@MIT.EDU, asedeno@MIT.EDU Subject: Re: [Curdle] [SSH] GSS key exchange methods In-Reply-To: <52268E1E6876438094A2D6E779F8145C@Khan> Message-ID: References: <52268E1E6876438094A2D6E779F8145C@Khan> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-739092933-1473529690=:5272" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrZvgfiXc4MBFMYsrizYwWWxdOIvZ 4mvbAzaLey+nMFp8uPeYzeLsBUWLaTtfMDmwezz5NJPd4/70eewe248sZPfYOesuu8eSJT+Z PBY+7GH0WDn1NHsAexSXTUpqTmZZapG+XQJXxvbJV1gKbhtXbF5whbmB8bhWFyMnh4SAicT2 mwfZuhi5OIQE2pgkNv5uYYZwNjJKHDl7jhGkSkjgEJPEjJ2OEIkGRommCZtYQRIsAtoS/zfs AStiE1CRmPlmIxuILSJgJrFtx22wGmaBBIlvi84xgdjCQOu23J/LDGJzAtmdzxrAbF4BB4mz W+9DLTOW6Hn/E6xXVEBHYvX+KSwQNYISJ2c+YYGY6S+xtv8z8wRGgVlIUrOQpCBsdYnGB2fZ IGxtifs329gWMLKsYpRNya3SzU3MzClOTdYtTk7My0st0rXQy80s0UtNKd3ECIoSdhfVHYxz /nodYhTgYFTi4d1heSVciDWxrLgy9xCjJAeTkijvNb3L4UJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeHPdgMp5UxIrq1KL8mFS0hwsSuK8XTMOhAsJpCeWpGanphakFsFkZTg4lCR4n4A0Chal pqdWpGXmlCCkmTg4QYbzAA1XABteXJCYW5yZDpE/xagoJc47AyQhAJLIKM2D6wUnsd1Mqq8Y xYFeEeY1BaniASZAuO5XQIOZgAY/3XoZZHBJIkJKqoHRUIz3iUaQ57rtx2RP2j6+1aljmKR3 vTfl38vacLNQgZMzLx4WsVy/nH35gR1lZ8t+6eaEhq/oZkji+hqomVBzfR/PLa4m/YS4Mh6p 8y/mzWR4fN22oSPpRtUaU6dNL50zv9SutLo/bUJ+UFWa2cfeT0altTeDc5Y1p56YdnPVuoX9 kq8Wvp2pxFKckWioxVxUnAgA9ayQBj0DAAA= Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-739092933-1473529690=:5272 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 10 Sep 2016, denis bider (Bitvise) wrote: > Hello Curdle, and the old SSH list: > =C2=A0 > I forward parts of a correspondence with Mike discussing the need to addr= ess > GSSAPI key exchange methods in the ssh-kex-sha2 draft: > =C2=A0 > https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-04 > =C2=A0 > - denis: > =C2=A0 > "RFC 4462 defines the following key exchange methods, which our SSH Clien= t and > Server implement. I am aware also of other implementations by other vendo= rs, and > we hear from users who use them: > =C2=A0 > https://tools.ietf.org/html/rfc4462 > =C2=A0 > The exchange methods parallel the DH key exchange methods, and are curren= tly: > =C2=A0 > gss-group1-sha1-* > gss-group14-sha1-* > gss-gex-sha1-* > =C2=A0 > The current version of the ssh-kex-sha2 draft mentions these, but only to > deprecate gss-gex-sha1-* and gss-group1-sha1-*. The draft allows > gss-group14-sha1-* as a MAY, but does not define any new versions of thes= e > methods to parallel the new DH methods. > =C2=A0 > These key exchange methods serve a valuable role in environments where it= is > possible to authenticate using Kerberos, which is in Unix realms and Wind= ows > domains. The existing trust relationship between the client and the serve= r can be [Obligatory note that the GSS-API is truly *generic*, in that I know of sites that use a GSS mechanism that backends to X.509 certificates instead of Kerberos. I'm willing to ignore the GSS NTLM variants, though :) ] > used in this case, and allows for host authentication without having to s= et up or > verify a host key on the client. This substantially improves security and > usability in these environments, since lack of proper host key verificati= on > procedures is a big security risk, but their presence is a big pain point= for > administration. These key exchange methods avoid that problem in environm= ents > that already have an existing trust network to begin with." It is quite useful in those environments, yes, but is not risk-free. The most glaring risk is when GSS is using Kerberos, Kerberos is using DNS lookups (without DNSSEC) to expand the hostname in the host-based service principal, and both GSSAPIKeyExchange and GSSAPIDelegateCredentials are in use (to use the openssh spellings). In this case, an attacker that can spoof DNS responses to point the user at an attacker-controlled machine that has valid Kerberos credentials, can obtain a valid TGT of that user, granting near-full privilege to act as that user! For this reason, we disable GSSAPIKeyExchange in environments where users are likely to use GSSAPIDelegateCredentials, as the risk is too large. > - Mike: > =C2=A0 > "You make a really good point, I did leave out the GSS-API updates and on= ly > deprecated the -sha1-* entries. > =C2=A0 > I suspect that the same reasons we defined groups 15, 16, 17, and 18 to u= se > sha512 would hold for gss-group* kex methods. so, adding: > =C2=A0 > Key Exchange Method Name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Reference=C2=A0=C2=A0=C2=A0=C2=A0 Note > gss-group14-sha256-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This Draft=C2=A0=C2=A0= =C2=A0 MAY > gss-group15-sha512-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This Draft=C2=A0=C2=A0= =C2=A0 MAY > gss-group16-sha512-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This Draft=C2=A0=C2=A0= =C2=A0 MAY > gss-group17-sha512-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This Draft=C2=A0=C2=A0= =C2=A0 MAY > gss-group18-sha512-*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This Draft=C2=A0=C2=A0= =C2=A0 MAY > =C2=A0 > would make sense." > =C2=A0 > -snip- > =C2=A0 > My proposal also included a suggestion to update the gss-gex- method. Sin= ce it > seems unlikely that the GSS methods will be implemented by resource-const= rained > devices - in order to use this, a device would have to be part of a Unix = realm or > a Windows domain - I suggested gss-gex-sha512-* to provide a hash that me= ets the > security level of any DH group. > =C2=A0 > Mike is currently unsure about updating gss-gex-. I don't feel strongly a= bout > this, because the DH group exchange methods are a bit of a can of worms (= FIPS > requires group validation that fails with deployed ephemeral groups). The= main > priority is that GSS methods serve a unique function, and it would provid= e value > to maintain them. > =C2=A0 > For the same reasons we define the DH groups, I think it makes sense to d= efine > the above groups. However, if I needed to pick only one, my priority woul= d be > gss-group15-sha512. This is for the same reasons I prefer > diffie-hellman-group15-sha512. It meets all security recommendations, bot= h in > terms of DH group size and hash size, and it is 2x faster than group 16, = which > has performance characteristics that begin to close the gap between denia= l of > service and normal rate of connections on busy servers. > =C2=A0 > Does anyone else second these suggestions? Sure; I'd like to see them. > Defining this will not affect servers and clients that do not have a use = for key > exchange and host authentication using Kerberos. Only folks who want to u= se this > will be affected. > =C2=A0 > I am aware of other implementations of these key exchange methods besides= ours, > including patches for popular open source software. I=E2=80=99m not sure = if PuTTY > implements them; I think it might just implement the user authentication = method > gssapi-with-mic. For the people who do implement this, I=E2=80=99m not su= re if they have > representation or awareness of this list. I believe the PuTTY patches were maintained out of tree for a while but did eventually make it in. I'll add a few more CCs that are or used to be in the business of maintaining patches for GSS SSH support. -Ben ---559023410-739092933-1473529690=:5272-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Sep 11 08:08:27 2016 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 4051B12B0F2 for ; Sun, 11 Sep 2016 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 j41ukTCGIUsP for ; Sun, 11 Sep 2016 08:08:25 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 8CB4312B09E for ; Sun, 11 Sep 2016 08:08:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5017C85EEC; Sun, 11 Sep 2016 15:08:24 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id C2A2085E7E for ; Sun, 11 Sep 2016 15:08:22 +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 WhM-AoVgpNwQ for ; Sun, 11 Sep 2016 15:08:22 +0000 (UTC) Received: from pps05.cites.illinois.edu (pps05.cites.illinois.edu [192.17.82.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 29A7984CEE for ; Sun, 11 Sep 2016 15:08:21 +0000 (UTC) Received: from uex134.ad.uillinois.edu (uex134.cites.illinois.edu [192.17.212.210]) by pps05.cites.illinois.edu (8.15.0.59/8.15.0.59) with ESMTPS id u8BDj4YZ006760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 11 Sep 2016 08:45:04 -0500 Received: from uex134.ad.uillinois.edu (192.17.212.210) by uex134.ad.uillinois.edu (192.17.212.210) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 11 Sep 2016 08:45:03 -0500 Received: from CITESHT1.ad.uillinois.edu (192.17.212.151) by uex134.ad.uillinois.edu (192.17.212.210) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sun, 11 Sep 2016 08:45:03 -0500 Received: from CHIMBX3.ad.uillinois.edu ([169.254.8.110]) by CITESHT1.ad.uillinois.edu ([128.174.34.206]) with mapi id 14.03.0301.000; Sun, 11 Sep 2016 08:45:03 -0500 From: "Basney, Jim" To: Curdle CC: "ietf-ssh@NetBSD.org" Subject: Re: [Curdle] [SSH] GSS key exchange methods Thread-Topic: [Curdle] [SSH] GSS key exchange methods Thread-Index: AQHSDDKyiBst1bODTUeFAVvMbC38HA== Date: Sun, 11 Sep 2016 13:45:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.2.14.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <5ED13BE4CBE28149A719334449D1D14B@mx.uillinois.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609110215 X-Spam-OrigSender: jbasney@illinois.edu X-Spam-Bar: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 9/10/16, 1:35 AM, denis bider (Bitvise) wrote: >Does anyone else second these suggestions? I do. Science projects like ligo.org and xsede.org rely on RFC 4462 SSH GSS-API Key Exchange using multiple GSS mechanisms including X.509 [1], SAML [2], and EAP [3]. We use patches [4] that add GSS-API Key Exchange support to OpenSSH, and we'd update the patches to support new GSS-API Key Exchange methods. Regards, Jim [1] https://github.com/globus/gsi-openssh [2] https://github.com/fedushare/mech_saml_ec [3] https://wiki.moonshot.ja.net/display/Moonshot/Source+Access [4] http://www.sxw.org.uk/computing/patches/openssh From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Sun Sep 11 13:14:36 2016 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 A9B4C12B0EC for ; Sun, 11 Sep 2016 13:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 TZcaEhnumnNx for ; Sun, 11 Sep 2016 13:14:35 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 628B312B0D2 for ; Sun, 11 Sep 2016 13:14:35 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 3D9C885E5D; Sun, 11 Sep 2016 20:14: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 2BEA784CFD for ; Sun, 11 Sep 2016 20:14: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 x-rzd4uNwDA4 for ; Sun, 11 Sep 2016 20:14:31 +0000 (UTC) Received: from pps01.cites.illinois.edu (pps01.cites.illinois.edu [192.17.82.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 47F6E84C6C for ; Sun, 11 Sep 2016 20:14:31 +0000 (UTC) Received: from uex1313.ad.uillinois.edu (uex1313.cites.illinois.edu [192.17.212.214]) by pps01.cites.illinois.edu (8.15.0.59/8.15.0.59) with ESMTPS id u8BJ2dhf030916 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 11 Sep 2016 14:02:39 -0500 Received: from uex1313.ad.uillinois.edu (192.17.212.214) by uex1313.ad.uillinois.edu (192.17.212.214) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 11 Sep 2016 14:02:39 -0500 Received: from CITESHT3.ad.uillinois.edu (192.17.212.153) by uex1313.ad.uillinois.edu (192.17.212.214) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sun, 11 Sep 2016 14:02:39 -0500 Received: from CHIMBX3.ad.uillinois.edu ([169.254.8.110]) by CITESHT3.ad.uillinois.edu ([128.174.34.208]) with mapi id 14.03.0301.000; Sun, 11 Sep 2016 14:02:38 -0500 From: "Basney, Jim" To: Curdle CC: "ietf-ssh@NetBSD.org" Subject: Re: [Curdle] [SSH] GSS key exchange methods Thread-Topic: [Curdle] [SSH] GSS key exchange methods Thread-Index: AQHSDDKyiBst1bODTUeFAVvMbC38HKB08+AA//+x1gA= Date: Sun, 11 Sep 2016 19:02:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.2.14.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <57EC21847C3FA246BC5C9C42EFC518ED@mx.uillinois.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609110300 X-Spam-OrigSender: jbasney@illinois.edu X-Spam-Bar: Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On 9/11/16, 1:42 PM, Benjamin Kaduk wrote: >On Sun, 11 Sep 2016, Basney, Jim wrote: > >> On 9/10/16, 1:35 AM, denis bider (Bitvise) wrote: >> >Does anyone else second these suggestions? >> >> I do. Science projects like ligo.org and xsede.org rely on RFC 4462 SSH >> GSS-API Key Exchange using multiple GSS mechanisms including X.509 [1], >> SAML [2], and EAP [3]. We use patches [4] that add GSS-API Key Exchange >> support to OpenSSH, and we'd update the patches to support new GSS-API >>Key Exchange methods. > >Do note that Simon is no longer actively maintaining those patchsets; I >believe the best place to send updates is a pull request to >https://github.com/gss-openssh/openssh-portable (which is itself a bit >under-loved), though I would be happy to hear that there is an alternate >home for such patches. Yes, I have previously submitted a pull request to that repo. Our offer to assist with maintaining that repo still stands. Our current, actively-maintained sources reside at [1]. Thanks, Jim >> [1] https://github.com/globus/gsi-openssh >> [2] https://github.com/fedushare/mech_saml_ec >> [3] https://wiki.moonshot.ja.net/display/Moonshot/Source+Access >> [4] http://www.sxw.org.uk/computing/patches/openssh From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 08:05:12 2016 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 BA2FF12B9A7 for ; Mon, 12 Sep 2016 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 CwzUahqsA-TU for ; Mon, 12 Sep 2016 08:05:08 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 B972E12B590 for ; Mon, 12 Sep 2016 07:35:58 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 49E5D85EA5; Mon, 12 Sep 2016 14:35:57 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 8AE9384C6C for ; Mon, 12 Sep 2016 14:35:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 4jx3LyReterz for ; Mon, 12 Sep 2016 14:35:52 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0092.outbound.protection.outlook.com [104.47.42.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3164C85E9B for ; Mon, 12 Sep 2016 14:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B1xAwguZUkXKsuIJbSN5HmhOrDmRufgt8vEnjXfDxKA=; b=gKIEmP2O519lytZZmNznLLe+vckADGMrHAYUSqar4rqJ7ZsY1RTDtdAHMZ3BXlNfVv/ufqRa32gTGZWCk2mml270Cce5aOdA/D6AXoesPVXYk59Z5BcblliBiBzS60VpwHpuBpX1jt0PuYhaIs+4CAmUGBmRMDtHDY0sZ/Keib8= Received: from SN1PR05CA0003.namprd05.prod.outlook.com (10.163.68.141) by BLUPR0501MB978.namprd05.prod.outlook.com (10.141.255.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.609.3; Mon, 12 Sep 2016 04:01:31 +0000 Received: from BN1BFFO11FD051.protection.gbl (2a01:111:f400:7c10::1:183) by SN1PR05CA0003.outlook.office365.com (2a01:111:e400:5197::13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Mon, 12 Sep 2016 04:01:31 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD051.mail.protection.outlook.com (10.58.145.6) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Mon, 12 Sep 2016 04:01:30 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 11 Sep 2016 21:01:29 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8C41ROO007549; Sun, 11 Sep 2016 21:01:27 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id F0F541141B; Sun, 11 Sep 2016 21:01:26 -0700 (PDT) To: Curdle CC: IETF SSH From: "Mark D. Baushke" Subject: draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 Date: Sun, 11 Sep 2016 21:01:24 -0700 Message-ID: <35923.1473652884@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(9170700003)(305945005)(356003)(87936001)(105596002)(110136002)(50466002)(86362001)(5003940100001)(229853001)(106466001)(4001520100001)(2906002)(4326007)(117636001)(53416004)(5660300001)(7126002)(8936002)(81166006)(626004)(8676002)(2810700001)(11100500001)(76506005)(50986999)(54356999)(48376002)(586003)(19580395003)(7696004)(92566002)(230783001)(15975445007)(47776003)(77096005)(189998001)(5001760100003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR0501MB978;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD051;1:1JB8bCxNS1sbp2UZEztJLa4/QI7FUqMpE3Qpl8iYDKC4I2wWyFosRncXZ3/65MBenxh6k3AjqxjYmQn34zeKxA3A1qb2w3bC+w/tObNWTx87udqFLEVX9SS0stRAGNbyAaPttUjc3zskcvHSTx58y1SAUlfHGJJ1GojucRLbjM8rZdldDeFm8T7j6QzDKY4nQUBSuHkkixPfE8KV84Y0KFYBMfVTW67isokWB5fInD8NrGOS8Tv+ca5mmwR+nhyPJgebPQgbW1cwcQxsyuE2eRshkdojpJZRiILXpIC0yXOXBbwSs8fbHkwBoujRZu6zRulWQm2NTM50LUMlWzbJPT+T/btN63Ek7Of9L3cHSaNQiLZfF2y9vPj/by1Zr7MLqUkTANuN/7ZmVb5LVZ3tRq0aCMCnccRkrcrqjx+l3pb4e8pa94zomzCr17aCdOu5rszFNc4/cOWxwy648x8SWH3BBN127ZAMIJlbEHBHM87/KpmWYLXTIRc8wx1h8DgPL+/5Za08CP2NupNLPacTaWkeziY6ivzkkXzYj31VcNY= X-MS-Office365-Filtering-Correlation-Id: db5799b0-207f-4df0-3d52-08d3dac17abb X-Microsoft-Exchange-Diagnostics: 1;BLUPR0501MB978;2:AIXDf8hsa5SOgxSQEWQdkjVbqBV96W01rXI9lxLB0JjNbRLLqtvriHmrWBN0sm8ZscTiRAXX8vTVbNJSJAvdmLWmAuH9MOsdX7nus89FWnneujjcBjqgO+rMiCaGAMpcwmHGUP17TfmejmCIIceHdu5Is/2ZlbLwNPdiyNdn6cmSYdtcG/0TSnmBoLhtml0E;3:syZx9MyPBMHe0Rkdym7X6rFClZlXO7LJnIggC3nk6zeRNR4/c+AoZqL+pR9PEhK/ZsctAuDGAO2FaVwdWl8hBdiYHu4Iuper6MdR9UeY8GPKDFudSPWGq1+x5Ui8JIm2Ycc8Ju3XTONh/CSFyLA13qgQPMtAB4RQkhZI1VVZFUj6erxBGd1LQ175VtvRbfOvShpmDtmK6RlfxsROqYICk3ko8ygVgv/O9shg+NMj3jQ=;25:QyBAlP06US8HDAggDTiHU9u9BQyhk0c0CAo+9wve5XrmVH6TVcb7GlUQkF4qf7qu9YTHWGafHhmOrDWBfJvYiWNIK4FmvHihHtqosnngA6FChTgnbPvFgEHoj6/nAeslXW53ILAPBPry45lsMY6iI0xL9ctLEUHIwK7s9ijsJP0F8u9yPA9LbHVeaymkmN6yXxkLFiRF443aVAncIOrtsisFLgaKT2Jyl/aaKqDSHooy1pGWhRhZ/RuoLfphMNFt1bOfj8h2YkxzcIe3eWrS4WzStYqdMeC5fNRbeU320h3bWk5OhIOj+70t+Tw+pb+oQ9C2RfbEdBTVy9xSzJprlgtcG6O9JvnxGOxA+PrNGJmik4rl0Ma7WmQR419yiXiPO3g584DqVbjNzy+Cn83PcypoWHrsVcis5rOEEyW/mXc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB978; X-Microsoft-Exchange-Diagnostics: 1;BLUPR0501MB978;31:/Jmo+/zn8H1I1jzxuAohI2wk3x744sP8hKBlimZLCcUVMFfcCbczDp+wM+yb2E+sgS49Au8T3nW6MmhnYFMzY8DCpYRjhYV6TIWg4mx15ijeEKiRV/pDzuYsXRLMILFBOlAAHo9jO1z4SYIQ2pGXmrvu3mvbXE/2JBTZBIQ56VwFvol1d1KqNLDK7gacTc7AmUk+pSVN98ryeJeybp7YHDkc9PYXHG5axbVa4ZwyGws=;20:BLKzBtrJU74pAWcrwwwrcTvqyx0Cz5LBWuX/Ir0BTNwayKmokcWCFkH6bzLEHcmBQ29mgo4xS+XFeoMMVt83jcPD0WHhG1U9TwfKnNPNGqCjMVPix/CQMXO4u8tXQDFxzMltbBNhtMI77geuxxL1C3Bdf9gaS4JSqfY4pMNEJPFUCsusIviu8kDASG/pnDVBmUMfyxL19KbIfrJ6dzhJwgA2VvI/MqQIDP/tZITsOgWl6uHYWmIwq0IA12V/IsFLtP5kRf+DxgEaDtpKgcxlEM2AHClpJWb9Tr8SCBqyHYyhaLXHfwKDjf5Vhrlw4CIEpS7S8sX9gJGnjRXhqYgmDq9OSryjnj55kNDDWDZfCOmVlaxgSTOnUCKWLT1lFl3wP3dMh48ogWULCqyLz6nriIXP+aJByX36cTANEqWj48W+O+C2TdHNAubUmcBHl3z88p2qt5RsISzy2g3Da34+ed+AbKqqUNSwDwpBTjvf1Xu84rHsoSsteCKmCWCNugsq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13017025)(13018025)(13015025)(13024025)(13023025)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:BLUPR0501MB978;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB978; X-Microsoft-Exchange-Diagnostics: 1;BLUPR0501MB978;4:I/CHjxrDfrpLn9eBojQNSJiOORpIFyiTpPmP/OqHyqZEa+neLdzrmdZH/yvDMxU6K32A2lx/bzKLPI/XXNTJmrX/Pc987QTat/KP8veYcmf+qOMlHAEHwKbqkcplo+cJ8yF3dyEmsK5l+e2YtijOchNu+Kqg3bgsEQmFcM146P9z9ahM1v+y2BY8GEiR8D8gs5uXHlemWOxCb35YTIZK8pfzkk+hvgbI7VNgEx7jqX0SLznk6NERkkjZF/rAZRTbtfRsK9G7lkZ3IT3MCV23kOZXw7R57tvFaKVQHTPfbaXK9tX4R51vmz27t1W08WLJLSE6rmB6mVgC8laiUYLOrlUT7O4U6DnEMarKuJFptQs04PDcYkrh91ouhelCZQStCrzX6un4quiV4xe6BwNkLMtdxKUTId/5oXaIxjbMhit8LIquJkdw9G23LTL+EQg0wTer5pdjp0IYg1lGb+2ZjaxMeIPFC4Ah2qel4oUugmVHC5VgqPx37f2xP2W3CJLs X-Forefront-PRVS: 006339698F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BLUPR0501MB978;23:kIYqbyv6U96zGKZURncmhw37W9lUMXUXwanXlzxH?= =?us-ascii?Q?Qf7yPoDcsKl03pulCCqby+Bsx5aVPubvzCXBVWxE3OuYh8Sf3ZyyYcZARxZn?= =?us-ascii?Q?5OUHiQV14MDGad1DvTuvtbOFqIL+P2P7iUh+Dswhjxb83sLNT/CjLspxkFJw?= =?us-ascii?Q?NBu0LiGtVLkPjLiDjjUrjux+n5EdUl/fTpp8WOKNbl4LnvFS6YBwTMtVXq4w?= =?us-ascii?Q?bEzI1EawoS5fsZSR2dqjme0JVfZcK6vBSYBMXCxhK9EBSyK/TnQPqdBkhjCS?= =?us-ascii?Q?GCzZzLuQzsR0sY0dGVO0tGotmjvWIemNEHmJOtP7reaicNIbvwv5NyeI+IFp?= =?us-ascii?Q?z79sZX1tTqZsY4y9gOZAtEarj2VEYpvSYv5abrxj6N9eLlNDd2IjODF1Z21q?= =?us-ascii?Q?tYJW+AwnF2U+bWfeB4BL1tY1zO5KLEnjqcUyfSNn/5knJPov42sJSDAMU4xr?= =?us-ascii?Q?gfu0caUhTJT/K6yS8ttj9E1zEiHJNSn0FiMFBB+4G3R9n/GQ45Cd1ws08vRO?= =?us-ascii?Q?4uYZfhQ1D8pkUI0hTG5c9utZ5Nz6AtRVbi9RdDfHuADu0auI0puPdSgnwa2g?= =?us-ascii?Q?BN3SpfE/Mr6UGFeD+pLBosWpo5i1qeF5SPFntfb/nBXNpaIAZj5K/5pd4yf8?= =?us-ascii?Q?ftCiCIqoVwdMHlpERG3Pu5jE1juXHJS/Y9vE1IbOLc8XONb50q4EebefPBiD?= =?us-ascii?Q?/gZ+Tzi54Cut4QGfZsw58KNGO5h65LZy4jK84y+en32oe/ZgLiv4FZtf8sWR?= =?us-ascii?Q?iyTAtuwvsyclxJyRwmiowmRo7g5n3FILnJolz8QaVT998cxcFDPVvJgSiHiW?= =?us-ascii?Q?6tRx+TDOsRaLU9qJ7wtcaL5pdeA4YY9fmCew7LlSrhw25QGZVoSIoaUuX5rT?= =?us-ascii?Q?RY5E5fpp2Phg+Ln4SJCWJqsQtSEu/0BHSByUt6cIWapz5fawsr+yEVarakZV?= =?us-ascii?Q?RekALQsI21u0AqmwmRv5LPyY485mCOQrE8EJF9QYQlYjrtqgptJ5JDhcw28p?= =?us-ascii?Q?eg5oBqdJKq3a3B2u34yJ4KjiQ7qJwD2flGWgDXjHKBSz1gHEgWvwtHQdso9v?= =?us-ascii?Q?xmMSrzqdk9p8RfhrsiMiHzPqFIt3WRcNRuEQUkIh3S/s8oZAtg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR0501MB978;6:pfswD6ykpWeisyzUDB+TA+56COv+frAVEezJvDeOgSjmUOC76eqlAeCZ54FKm9Elk60VyTB7J/oKt1NpVTysN/9y4gJVIysKPo4C6k+aUKDDLmkT1an4Avz055Rq04vOf0HbD4BPXfb/pZBh86nm0iGhc21DmvazKILK385WqsvQaUUSvme0BSNvHxBNgirgrU4znMd5da/z6QlVaem/uN9RHxAOYumryIN2TVwDRfoqITsJ/AH+p5c3E9hWYlgZG9utroGOw1C+g3siHUUtcfcZhig9+SCVFcRY/DXhoGueGklMAU+6UujvP0bYy7BGmZBej117R04HiXnEy2EV4w==;5:ideI9ZiHtLKBaeXhtRh9ljH3855NCOBBLGjNqmODYKhJ94rY0vgqyyuazxU9ookHRrJjVhE+v0nkD9eokQ2Vaqbm0lkcRahQJJFr+R9HklLazifU40Uu7GkMAaxbn38nk6PkHBJKU9WHP/Z/YnERqQ==;24:nQSpWBRBFLINyjCQuYbX0kugRYS6KnTHNrkKKr7neNdFnYWLgJLgUAngY5d1R6axSLJ8OouD3u9yLgX6wTcBTSz7BWKDXnMF2xffLNbbPXA=;7:nlAHV3w/TZtcsgNJ4wICEeBfUrLZOXMA5ve7+HkkxJ33/oDk565VJPSLBPuW4d9EIkxnSounN2D6Cv/F7UwGFmPHTf/XsOM34sPINWYXZ0uXass1gJO3fOz1nHvmFW/i8T4E3c54oEMlgNhHKaoUhlnoWoiqQaYwtMLq0M2Hp52/a088twyxDCLDa4mNl6WdaxtjaY2HTz4SuEJhjUzf8Y7mV3VmW8SlfD8g6Mexa74hsdSa7ycVWRjUvGHqBSV5 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2016 04:01:30.8418 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB978 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I have split out a new draft draft-ietf-curdle-ssh-modp-dh-sha2 [1] (called "new-modp" in the Reference table below) forked from the draft-ietf-curdle-ssh-kex-sha2-04 draft. It specifies the new MOD DH KEX Groups that use SHA-2 hashes. This edition specifies both the new diffie-hellman-group* names of the -04 revision as well as adding the gss-group* names. Before I update draft-ietf-curdle-ssh-kex-sha2-05 to point to it, I would like to take a straw poll of which algorithms (if any) should be defined as a MUST to implement. My personal preference was just curve25519-sha256. However, at least a few implementors have said that they were not planning to do any ECDH implementations. So, I am guessing that "diffie-hellman-group14-sha256" may be the only one that everyone might be able to agree is a MUST to implement. Key Exchange Method Name Reference Note curve25519-sha256 ssh-curves MUST curve448-sha512 ssh-curves MAY diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group15-sha512 new-modp MAY diffie-hellman-group16-sha512 new-modp SHOULD diffie-hellman-group17-sha512 new-modp MAY diffie-hellman-group18-sha512 new-modp MAY ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp521 RFC5656 SHOULD ecdh-sha2-* RFC5656 MAY ecmqv-sha2 RFC5656 MAY gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha1-* RFC4462 SHOULD gss-group14-sha256-* new-modp SHOULD gss-group15-sha512-* new-modp MAY gss-group16-sha512-* new-modp SHOULD gss-group17-sha512-* new-modp MAY gss-group18-sha512-* new-modp MAY gss-* RFC4462 MAY rsa1024-sha1 RFC4432 SHOULD NOT rsa2048-sha256 RFC4432 MAY I plan to post the above table in the new draft-ietf-curdle-ssh-kex-sha2-05 draft after 05:00 UTC on 12 September 2016. Of course, everyone can still lobby for changes with the Curdle group, I just don't want to generate a huge number of revisions if possible. Thank you, -- Mark URL: [1] https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-00 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 09:59:20 2016 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 DEC3F1200DF for ; Mon, 12 Sep 2016 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 MZAXpMHdbEz1 for ; Mon, 12 Sep 2016 09:59:19 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 6F2B9126FDC for ; Mon, 12 Sep 2016 09:59:19 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 97A8585EB5; Mon, 12 Sep 2016 16:59:17 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4117285EAE; Mon, 12 Sep 2016 16:59:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 879ED84CFD for ; Sun, 11 Sep 2016 18:42:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id SdpmPy0wweRZ for ; Sun, 11 Sep 2016 18:42:27 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C566884CF5 for ; Sun, 11 Sep 2016 18:42:26 +0000 (UTC) X-AuditID: 1209190f-b0bff7000000371b-e4-57d5a591ab4e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 82.DD.14107.195A5D75; Sun, 11 Sep 2016 14:42:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8BIgO5o002627; Sun, 11 Sep 2016 14:42:25 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8BIgLPq016616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Sep 2016 14:42:24 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8BIgLXR005607; Sun, 11 Sep 2016 14:42:21 -0400 (EDT) Date: Sun, 11 Sep 2016 14:42:20 -0400 (EDT) From: Benjamin Kaduk To: "Basney, Jim" cc: Curdle , "ietf-ssh@NetBSD.org" Subject: Re: [Curdle] [SSH] GSS key exchange methods In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixCmqrDtx6dVwg+nHzS22LpzFbPHh3mM2 iyPntB2YPZYs+cnksWjqdiaPhQ97GAOYo7hsUlJzMstSi/TtErgyNt6ILZjMWdF79RJrA+MF 9i5GDg4JAROJb4cLuxi5OIQE2pgkTt1tY4RwNjJKHL10k7mLkRPIOcQkseeLCITdwCixcUcE iM0ioC1x7ehqsBo2ARWJmW82soEMFRHQkOjZqAwSZhbwlPh8cxcLiC0MtGvL/blg5ZwCxhKf n+xjA7F5BRwk5u/rZQRpFRIwkmh8kAMSFhXQkVi9fwoLRImgxMmZT1ggRmpJLJ++jWUCo8As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBIemJP8OxjkN3ocY BTgYlXh4A0KvhguxJpYVV+YeYpTkYFIS5fVfABTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvth PlCONyWxsiq1KB8mJc3BoiTO2zXjQLiQQHpiSWp2ampBahFMVoaDQ0mCd+sSoEbBotT01Iq0 zJwShDQTByfIcB6g4aUgNbzFBYm5xZnpEPlTjIpS4rwMIAkBkERGaR5cLzh17GZSfcUoDvSK MO8VkCoeYNqB634FNJgJaPDTrZdBBpckIqSkGhi36Wu6snh539xqtu5+p0lpoq9d67mZGcFS t76xxFuuYr/qHC53w3rrCn7/+9/cObXrtSY2h9y7+zilsKHDfpZk4/bdP8vyKnf8/7h6S+cP S72zt25VLdnifup70+zlJ3YdTs/yzpJp/WAmPEvrxvKFXZN5Ly3i1jyTcDNrv16sBPPf9Gmt T3SVWIozEg21mIuKEwHSlf2x+AIAAA== Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 11 Sep 2016, Basney, Jim wrote: > On 9/10/16, 1:35 AM, denis bider (Bitvise) wrote: > >Does anyone else second these suggestions? > > I do. Science projects like ligo.org and xsede.org rely on RFC 4462 SSH > GSS-API Key Exchange using multiple GSS mechanisms including X.509 [1], > SAML [2], and EAP [3]. We use patches [4] that add GSS-API Key Exchange > support to OpenSSH, and we'd update the patches to support new GSS-API Key > Exchange methods. Do note that Simon is no longer actively maintaining those patchsets; I believe the best place to send updates is a pull request to https://github.com/gss-openssh/openssh-portable (which is itself a bit under-loved), though I would be happy to hear that there is an alternate home for such patches. -Ben > Regards, > Jim > > [1] https://github.com/globus/gsi-openssh > [2] https://github.com/fedushare/mech_saml_ec > [3] https://wiki.moonshot.ja.net/display/Moonshot/Source+Access > [4] http://www.sxw.org.uk/computing/patches/openssh > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 09:59:31 2016 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 7EF28128E18 for ; Mon, 12 Sep 2016 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 IGgp-GTzWjwB for ; Mon, 12 Sep 2016 09:59:29 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 A18AF127A91 for ; Mon, 12 Sep 2016 09:59:25 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6B72785EC0; Mon, 12 Sep 2016 16:59:25 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 2736685EBF; Mon, 12 Sep 2016 16:59:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0B5A285E54 for ; Mon, 12 Sep 2016 13:09:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id ceWoJOU45X97 for ; Mon, 12 Sep 2016 13:09:18 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 3183585E13 for ; Mon, 12 Sep 2016 13:09:13 +0000 (UTC) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8CD8xeR012322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Sep 2016 16:08:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8CD8wi6025340; Mon, 12 Sep 2016 16:08:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22486.43242.802279.610275@fireball.acr.fi> Date: Mon, 12 Sep 2016 16:08:58 +0300 From: Tero Kivinen To: "Mark D. Baushke" Cc: Curdle , IETF SSH Subject: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <41049.1473653352@eng-mail01.juniper.net> References: <41049.1473653352@eng-mail01.juniper.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes: > Key Exchange Method Name Reference Note > curve25519-sha256 ssh-curves MUST > diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT > diffie-hellman-group1-sha1 RFC4253 SHOULD NOT > diffie-hellman-group14-sha1 RFC4253 SHOULD > diffie-hellman-group14-sha256 new-modp MUST > diffie-hellman-group16-sha512 new-modp SHOULD > ecdh-sha2-nistp256 RFC5656 SHOULD > ecdh-sha2-nistp384 RFC5656 SHOULD > ecdh-sha2-nistp521 RFC5656 SHOULD > gss-gex-sha1-* RFC4462 SHOULD NOT > gss-group1-sha1-* RFC4462 SHOULD NOT > gss-group14-sha1-* RFC4462 SHOULD > gss-group14-sha256-* new-modp SHOULD > gss-group16-sha512-* new-modp SHOULD > rsa1024-sha1 RFC4432 SHOULD NOT (I remove algorithms with status of MAY, to make it shorter). That looks mostly ok. Most of the sha1 -> SHOULD NOT, with exception to the diffie-hellman-group14-sha1 and gss-group-14-sha1-*, which are still kept as SHOULD for backwards compatible reasons. The MUSTs are good, but there seems to be quite a lot of SHOULD versions. Is there really need for that many SHOULD algoritms. For example is there reason to keep ecdh-sha2-* as SHOULD when curve25519-sha256 will be MUST? Also, is there need to update other algorithms, i.e. encryption algorithms, MAC algorithms, Public key names, comperssion algorithms etc? Are the implementation requirements for them up to date (I do not know, as I have no idea which of them are now mandatory to implement, and which are not). -- kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 09:59:40 2016 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 6FA67128E19 for ; Mon, 12 Sep 2016 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 ELcANWYwAMDJ for ; Mon, 12 Sep 2016 09:59:34 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 287E7128874 for ; Mon, 12 Sep 2016 09:59:34 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id D4D7885ED2; Mon, 12 Sep 2016 16:59:33 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 7C65385EBF; Mon, 12 Sep 2016 16:59:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 92F0D85E13 for ; Mon, 12 Sep 2016 02:39:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net 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 r_gjW-mNJSJH for ; Mon, 12 Sep 2016 02:39:09 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id C802C84CE5 for ; Mon, 12 Sep 2016 02:39:09 +0000 (UTC) Received: by mail-pa0-x235.google.com with SMTP id b2so46175274pat.2 for ; Sun, 11 Sep 2016 19:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:mime-version:subject:message-id:date:to; bh=hAs7/RM3TWdirF4Kmhq5NyiSIMI7KFhE8yOFAUruo5E=; b=YUBKao0rI+fBVsAHyeLbgRfvQ2a5siD+hx0TBqaMgf7hnikGzuTHJQow/Mvf6vD3+R QjnB7I85eZECLMiR2J3UsQdHezYfVTYwbVvS75Q5YWIaJdWSBxFMrNqn2onTkkVDsIGH 80ruhTxMuk0+xQvdDk9b/xRAeeYQrUOD1NEDc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=hAs7/RM3TWdirF4Kmhq5NyiSIMI7KFhE8yOFAUruo5E=; b=Z75FaR/2DeXVC3pJH9oFpLr1IxGQN8cb5Jbh8stFu4s5UW7KAfnMYiwBTb+1JaRYpE eyQHmiXfwK9c8SS3ymP61g+Gv9yEYj0A1Vdd4dyzfb1nd+X60qDatlbjQci+85+jT+sk 2D/xf9UCm1TXjU0N1sPs9t1yHH1P4bTw2bNF+g4wH6K12QML+o3bHpgIkIXDUx7gn6Or D4EEmAJiCbLa9FWQp+wiQayoZJcZE/nhb3KVOofSrWKENoIcvSgNpjtq1sqUqHvO0iiv Wesrn+Ek4aWZ/kthjSUv7KuySbTxxJjGiA9oitYIMt4t2rP1dCtaXw2+YF4k2QBW1pGu IpzQ== X-Gm-Message-State: AE9vXwOiomikJf4R/JUYMINGcvLVtqNR7fmsn2R5CyEo3SfbD6JFe/eotxynNkXcDvTSDw== X-Received: by 10.67.7.170 with SMTP id dd10mr29254803pad.152.1473647949119; Sun, 11 Sep 2016 19:39:09 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id p17sm20062223pfi.7.2016.09.11.19.39.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Sep 2016 19:39:08 -0700 (PDT) From: Ron Frederick Content-Type: multipart/alternative; boundary="Apple-Mail=_1D690562-ED0A-45A1-9063-3214D2BD3C7E" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3225\)) Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Message-Id: <88F8D101-CBAA-4E57-AD25-8F403B6B57BC@timeheart.net> Date: Sun, 11 Sep 2016 19:39:07 -0700 To: ietf-ssh@netbsd.org X-Mailer: Apple Mail (2.3225) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_1D690562-ED0A-45A1-9063-3214D2BD3C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis Bider (Bitvise) wrote: > If you are sending an rsa-sha2-XXX signature, you cannot set all 3 = fields in the authentication request to "ssh-rsa", because then this = makes for a SHA-1 signature as it was done traditionally, not a SHA-2 = signature. To send a SHA-2 signature, at least one field has to contain = "rsa-sha2-XXX". > =20 > The draft specifically says the signature format names are = "rsa-sha2-XXX", but the public key format name stays "ssh-rsa", which it = must stay in order to preserve existing RSA key fingerprints. > =20 > The signature format is defined thus: > =20 > string "rsa-sha2-256" / "rsa-sha2-512" > string rsa_signature_blob > =20 > These specifications seem to me very clear and unambiguous. In a user = authentication request, when sending a SHA-2 signature, the only correct = encoding of algorithm names is as follows: > =20 > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service name > string "publickey" > boolean TRUE > string "rsa-sha2-256" / "rsa-sha2-512" > string public key blob: > string "ssh-rsa" > mpint e > mpint n > string signature: > string "rsa-sha2-256" / "rsa-sha2-512" > string rsa_signature_blob > If your implementation does not encode the algorithm names this way, = it is incorrect. The latest OpenSSH versions encode the algorithm names = this way, though a previous version used "ssh-rsa" in the third field by = mistake. > =20 > Bitvise SSH Client encodes the fields this way also, and the current = version of Bitvise SSH Server expects the algorithm names this way, and = only this way. I did an implementation of this recently for AsyncSSH, and I have = matched the above in the case where regular keys are used, with the = first and third identifiers being rsa-sha2-256/rsa-sha2-512 and the = second identifier remaining ssh-rsa when the new-style signatures are = used. However, I also wanted to verify the correct identifiers to use in = the certificate case. Right now, I=E2=80=99m using ssh-rsa-cert-v01@openssh.com = as both the first and second = identifier in the certificate case, and only using = rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the = signature. This seems to work when talking to an OpenSSH server, and in = fact OpenSSH doesn=E2=80=99t seem to accept the certificate if the first = identifier does not identify that a certificate is being used, even if = the second identifier indicates that a certificate was provided as the = public key blob. I know that certificates are OpenSSH-specific, so my apologies in = advance if this is the wrong list to ask this question on. I just = happened to see this thread in the mailing list archive, and though it = would be good to get confirmation from the group. --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_1D690562-ED0A-45A1-9063-3214D2BD3C7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis Bider (Bitvise) wrote:
If you are sending an rsa-sha2-XXX = signature, you cannot set all 3 fields in the authentication request to = "ssh-rsa", because then this makes for a SHA-1 signature as it was done = traditionally, not a SHA-2 signature. To send a SHA-2 signature, at = least one field has to contain "rsa-sha2-XXX".
 
The draft specifically says the = signature format names are "rsa-sha2-XXX", but the public key format = name stays "ssh-rsa", which it must stay in order to preserve existing = RSA key fingerprints.
 
The signature format = is defined thus:
 
  string    "rsa-sha2-256" / = "rsa-sha2-512"
  string    = rsa_signature_blob
 
These specifications seem to me very clear and unambiguous. = In a user authentication request, when sending a SHA-2 signature, the = only correct encoding of algorithm names is as follows:
 
byte      = SSH_MSG_USERAUTH_REQUEST
string    user name
string    = service name
string    "publickey"
boolean   = TRUE
string    "rsa-sha2-256"= / "rsa-sha2-512"
string    public key blob:
  = string    "ssh-rsa"
  mpint     e
  = mpint     n
string    signature:
  = string    "rsa-sha2-256" / = "rsa-sha2-512"
  string    = rsa_signature_blob
If your implementation does not encode the algorithm names = this way, it is incorrect. The latest OpenSSH versions encode the = algorithm names this way, though a previous version used "ssh-rsa" in = the third field by mistake.
 
Bitvise SSH Client encodes the fields this way also, and the = current version of Bitvise SSH Server expects the algorithm names this = way, and only this way.

I did an implementation of = this recently for AsyncSSH, and I have matched the above in the case = where regular keys are used, with the first and third identifiers being = rsa-sha2-256/rsa-sha2-512 and the second identifier remaining ssh-rsa = when the new-style signatures are used. However, I also wanted to verify = the correct identifiers to use in the certificate case.

Right now, I=E2=80=99m = using ssh-rsa-cert-v01@openssh.com as both the first and = second identifier in the certificate case, and only using = rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the = signature. This seems to work when talking to an OpenSSH server, and in = fact OpenSSH doesn=E2=80=99t seem to accept the certificate if the first = identifier does not identify that a certificate is being used, even if = the second identifier indicates that a certificate was provided as the = public key blob.

I know that certificates are OpenSSH-specific, so my = apologies in advance if this is the wrong list to ask this question on. = I just happened to see this thread in the mailing list archive, and = though it would be good to get confirmation from the group.
-- 
Ron = Frederick
ronf@timeheart.net



= --Apple-Mail=_1D690562-ED0A-45A1-9063-3214D2BD3C7E-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 11:42:41 2016 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 96C3412B058 for ; Mon, 12 Sep 2016 11:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 3vOCLeaDTlVs for ; Mon, 12 Sep 2016 11:42:38 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 A6AD812B067 for ; Mon, 12 Sep 2016 11:42:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id E37FA85ECB; Mon, 12 Sep 2016 18:42: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 EE71685EBF for ; Mon, 12 Sep 2016 18:42:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id SUha1j8KM-bc for ; Mon, 12 Sep 2016 18:42:29 +0000 (UTC) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0090.outbound.protection.outlook.com [104.47.38.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 9B36785F18 for ; Mon, 12 Sep 2016 18:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D3aNnzl6Y2O3T6obOwwZsYX7hxdcWjmIWTFjXJ9mbpI=; b=a3StKqObRNzsalWeAxu2WOcr8vN1hm7pvqlUadMLoh0JCZIfBdOAgb+761HRt8VN5FcyvAt8LK2fbyHKwctONT4vmtxPgP/C/O/94n6Mv5p1jInBJLjBVPHCBJC9rVAtbhdyTjzNDwPTdgGscLq9hu3++w/1N4hj7K+qKOzuiQQ= Received: from BY2PR05CA041.namprd05.prod.outlook.com (10.141.250.31) by BN3PR0501MB1186.namprd05.prod.outlook.com (10.160.113.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Mon, 12 Sep 2016 18:26:35 +0000 Received: from BY2FFO11OLC001.protection.gbl (2a01:111:f400:7c0c::104) by BY2PR05CA041.outlook.office365.com (2a01:111:e400:2c5f::31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Mon, 12 Sep 2016 18:26:35 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11OLC001.mail.protection.outlook.com (10.1.15.185) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Mon, 12 Sep 2016 18:26:34 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 12 Sep 2016 11:26:30 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8CIQSi6007808; Mon, 12 Sep 2016 11:26:28 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 520091144E; Mon, 12 Sep 2016 11:26:28 -0700 (PDT) To: Tero Kivinen CC: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <22486.43242.802279.610275@fireball.acr.fi> References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Mon, 12 Sep 2016 16:08:58 +0300." From: "Mark D. Baushke" Date: Mon, 12 Sep 2016 11:26:28 -0700 Message-ID: <54981.1473704788@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(9170700003)(2950100001)(15975445007)(86362001)(50466002)(356003)(2906002)(47776003)(4326007)(2810700001)(87936001)(305945005)(77096005)(48376002)(5004840100003)(19580395003)(189998001)(11100500001)(586003)(19580405001)(4001520100001)(76506005)(5003940100001)(76176999)(7696004)(92566002)(626004)(5660300001)(7126002)(50986999)(106466001)(53416004)(230783001)(8936002)(81166006)(8676002)(117636001)(105596002)(110136003)(54356999)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0501MB1186;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11OLC001;1:nPKnlLuv/BlNUf/81tLUThPeZUVl1PGMW4P8WoCYNiFyK6OS3NG1UCqzKMkApkb68fC5DI+q2IGayplItp1KKIHcf5RcAodBj9GRGLgzSvkDC/ANO6y41v2Jj3lSmYZGDo3DnHzyouy65ggLaFs6h/q2rD0pNA8yG0T5nQfr9aeckvR/0lRb3Tv8Vkzc3KfdeJAJgpPi4jnoejUCA7Hdz5oUov+8t3nQ8yLpeb4s+eGd27vkFvlXo6DOL8AePPszgV0h1jepEKI43FAb+2Y6DZsEn7z71qmztbZRC53VND0OzLlAhOkycKOSCSaIgv+PyHlGfOy/xOeK6H7jFaL9eatosO/pEeUiR8DugmsA27629HE86JCdvx6TwG1FpHdAgFFsoCCGjmeU4M4UyMck4wusG5Ln/sRl8yq68SReUzijejb0v0bMTJGZU5EyJTT86YkLIeae32DJJKH2kcg3ttWNwLEF95EXKVNhr5EaWVgvxU9Xtskgan6s81Au+6+jzh8PjeZ6uG2RpcGWh3p1sKkkClfqIaEYSshF5dP+JFfPsp83ZxAuRmoZsTsaP5tz X-MS-Office365-Filtering-Correlation-Id: bbb29133-5377-4df0-77a5-08d3db3a538b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1186; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(13015025)(13017025)(13023025)(13024025)(13018025)(10201501046)(3002001)(6055026);SRVR:BN3PR0501MB1186;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1186; X-Forefront-PRVS: 006339698F X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2016 18:26:34.3267 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1186 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list [Regretfully an incomplete draft of this escaped prematurely, pardon the repetition. -- Mark] Tero Kivinen writes: > That looks mostly ok. Most of the sha1 -> SHOULD NOT, with exception > to the diffie-hellman-group14-sha1 and gss-group-14-sha1-*, which are > still kept as SHOULD for backwards compatible reasons. Yes. > The MUSTs are good, but there seems to be quite a lot of SHOULD > versions. Is there really need for that many SHOULD algoritms. For > example is there reason to keep ecdh-sha2-* as SHOULD when > curve25519-sha256 will be MUST? I will move ecdh-sha2-* to MAY. The RFC5656 Section 4 said that every SSH ECC implementation MUST implement ECDH key exchange. So, I was moving all of those MUST to SHOULD requirements. It is not clear to me if the curve25519 and curve448 KEX method would fall into the RFC 5656 MUST requirements or not. > Also, is there need to update other algorithms, i.e. encryption > algorithms, MAC algorithms, Public key names, comperssion algorithms > etc? Are the implementation requirements for them up to date (I do not > know, as I have no idea which of them are now mandatory to implement, > and which are not). Good question. I am not sure if they are all being managed by the Curdle Group or not.... I am not sure that they all belong in one document or not. It seems like it might be better for each section to have its own document specifying the MUST/SHOULD/MAY/SHOULD NOT advise... The current IANA SSH Parameters are provided in: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml 1) Encryption algorithms We have a new one algorithm in Curdle: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ but I do not see any drafts for SSH yet to use it yet. I would favor seeing chacha20-poly1305@openssh.com become chacha20-poly1305 if someone wants to write a draft for it. I suspect that one or more of these encryption ciphers should be avoided (des-cbc and the arcfour* algorithms). I am not sure of the state of all of them. The SSH Encryption Algorithm Name list has the following IANA table: Encryption Algorithm Name Reference Note 3des-cbc [RFC4253] Section 6.3 blowfish-cbc [RFC4253] Section 6.3 twofish256-cbc [RFC4253] Section 6.3 twofish-cbc [RFC4253] Section 6.3 twofish192-cbc [RFC4253] Section 6.3 twofish128-cbc [RFC4253] Section 6.3 aes256-cbc [RFC4253] Section 6.3 aes192-cbc [RFC4253] Section 6.3 aes128-cbc [RFC4253] Section 6.3 serpent256-cbc [RFC4253] Section 6.3 serpent192-cbc [RFC4253] Section 6.3 serpent128-cbc [RFC4253] Section 6.3 arcfour [RFC4253] Section 6.3 idea-cbc [RFC4253] Section 6.3 cast128-cbc [RFC4253] Section 6.3 none [RFC4253] Section 6.3 des-cbc [FIPS-46-3] HISTORIC, See page 4 arcfour128 [RFC4345] arcfour256 [RFC4345] aes128-ctr [RFC4344] aes192-ctr [RFC4344] aes256-ctr [RFC4344] 3des-ctr [RFC4344] blowfish-ctr [RFC4344] twofish128-ctr [RFC4344] twofish192-ctr [RFC4344] twofish256-ctr [RFC4344] serpent128-ctr [RFC4344] serpent192-ctr [RFC4344] serpent256-ctr [RFC4344] idea-ctr [RFC4344] cast128-ctr [RFC4344] AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 2) MAC Algorithm Names has the following IANA table: MAC Algorithm Name Reference Note hmac-sha1 [RFC4253] Section 6.4 hmac-sha1-96 [RFC4253] Section 6.4 hmac-md5 [RFC4253] Section 6.4 hmac-md5-96 [RFC4253] Section 6.4 none [RFC4253] Section 6.4 AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 hmac-sha2-256 [RFC6668] Section 2 hmac-sha2-512 [RFC6668] Section 2 Of the above, I believe that hmac-sha1-96, hmac-md5-96, and hmac-md5 are considered insecure by some parties. As RFC 5647 was informational rather than standard track and does not play well with SSH negotiation of Cipher+MAC, I am not sure how to count it. Unless someone wants to play with SHA-3 (FIPS PUB 202), or revise RFC 5647, I do not see any real changes needed. 3) Public Key Algorithm Names Changes in flight are: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ Public Key Algorithm Name Reference Note ssh-dss [RFC4253] Section 6.6 ssh-rsa [RFC4253] Section 6.6 spki-sign-rsa [RFC4253] Section 6.6 spki-sign-dss [RFC4253] Section 6.6 pgp-sign-rsa [RFC4253] Section 6.6 pgp-sign-dss [RFC4253] Section 6.6 null [RFC4462] Section 5 ecdsa-sha2-* [RFC5656] x509v3-ssh-dss [RFC6187] x509v3-ssh-rsa [RFC6187] x509v3-rsa2048-sha256 [RFC6187] x509v3-ecdsa-sha2-* [RFC6187] The ssh-dss and ssh-rsa algorithms use SHA-1 and the ssh-dss for values less than 2048-bits seems unlikely to be very secure today. 4) Compression Algorithms I don't see a need to update these... Compression Algorithm Name Reference Note none [RFC4253] Section 6.2 zlib [RFC4253] Section 6.2 There are other SSH Parameters, I am not sure if any others need to be deprecated at this time. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 12:49:05 2016 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 0F97612B0ED for ; Mon, 12 Sep 2016 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 afqkGbDwIyH1 for ; Mon, 12 Sep 2016 12:49:03 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 BCE0F12B0E7 for ; Mon, 12 Sep 2016 12:49:03 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 6139885EC1; Mon, 12 Sep 2016 19:49:02 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 34F1385EB5 for ; Mon, 12 Sep 2016 19:48:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id PP6x_9OUhFOk for ; Mon, 12 Sep 2016 19:48:55 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0139.outbound.protection.outlook.com [104.47.42.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 0EC2985EB0 for ; Mon, 12 Sep 2016 19:48:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pyLv9Jc+vrH2CJe1o2hB4ldq5yYaEkrjXkp9zA4Ll1s=; b=R+mxQ6SLeECj/AgZ91Kl1KabIbzZmPnM5vY0zwEwu6kJDelFrChWO16+K2VKFvGcWaGXHty64BmNyVcYC0xotrpfiYrr1v6Et7Z9pKcGvQWtnAlaf60hyja7nmiMweudaayRH3rf8gJVRnh1emitleQmh/8r1ucjMuSTs/tKQ3E= Received: from MWHPR05CA0020.namprd05.prod.outlook.com (10.168.242.158) by BLUPR0501MB979.namprd05.prod.outlook.com (10.141.255.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Mon, 12 Sep 2016 18:15:30 +0000 Received: from BN1AFFO11FD026.protection.gbl (2a01:111:f400:7c10::156) by MWHPR05CA0020.outlook.office365.com (2603:10b6:300:59::30) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.544.10 via Frontend Transport; Mon, 12 Sep 2016 18:15:28 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD026.mail.protection.outlook.com (10.58.52.86) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Mon, 12 Sep 2016 18:15:27 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 12 Sep 2016 11:15:17 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8CIFFev005650; Mon, 12 Sep 2016 11:15:16 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 6E8C81141B; Mon, 12 Sep 2016 11:15:15 -0700 (PDT) To: Tero Kivinen CC: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <22486.43242.802279.610275@fireball.acr.fi> References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Mon, 12 Sep 2016 16:08:58 +0300." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(9170700003)(2950100001)(53416004)(189998001)(19580395003)(19580405001)(47776003)(5003940100001)(76506005)(7696004)(92566002)(5660300001)(7126002)(110136003)(356003)(626004)(86362001)(105596002)(305945005)(230783001)(8676002)(87936001)(117636001)(586003)(50226002)(15975445007)(77096005)(50466002)(76176999)(2810700001)(50986999)(2906002)(4326007)(48376002)(81166006)(5004840100003)(106466001)(8936002)(4001520100001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR0501MB979;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD026;1:WrwX6tpW1bNrsuiYWYCgPsPnRtQza6TK6+TxunKm/hln5sewX8wglohUHrtWigQZkCMXbXXnATBP4OUlZ+CwTAjoKE7nzHrIBLUy9LkrpwE0ypk+fo8TMVwjG1GUbs+d2hsGyAPiOiCdmNPvXu3Moi2oI9u5lxPGli6ZBSWDjklR61uAFaWm1Vase+wxpdL2grqtIw3qnvZGLAH+MwwiP9BXkIyzAy+c+hameWhGGvHL+b/Je3NGvzg6EgEGdr4Jw599AAc+MgaQQ4/1sUxxRK+2korw/8cLBFVV85F6YCnsAJOKJc+PszUzFvRCfV6UHqQRdtPCk/KABRRgJ+iY7as/Z4XYTUyKnMgcqYZ2CUQ9i7zG7W7oAl4CDWUS2A7THXEM6h+/JggVsOgAHkTiV4gtDOtaVuSd0yOf6CtzBas4ISePsJt2LeAu2BZzDUpwpMNPki/YsBlGfYbNcVE1DgSLKttRVtC7cXYvnky93hZdvBsSIbVPlUwFGQheGceLIXtG9TO8PafWyUvg6k8OT1Z/PY3luBHuR2U4dtjJxfAndHHE+oK4yAr9BD71pHal X-MS-Office365-Filtering-Correlation-Id: 98ae1c30-ea78-44e0-f01a-08d3db38c674 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB979; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(13017025)(13018025)(13024025)(13015025)(13023025)(10201501046)(3002001)(6055026);SRVR:BLUPR0501MB979;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB979; X-Forefront-PRVS: 006339698F X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2016 18:15:27.9987 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB979 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Tero Kivinen writes: > That looks mostly ok. Most of the sha1 -> SHOULD NOT, with exception > to the diffie-hellman-group14-sha1 and gss-group-14-sha1-*, which are > still kept as SHOULD for backwards compatible reasons. Yes. > The MUSTs are good, but there seems to be quite a lot of SHOULD > versions. Is there really need for that many SHOULD algoritms. For > example is there reason to keep ecdh-sha2-* as SHOULD when > curve25519-sha256 will be MUST? I will move ecdh-sha2-* to MAY. The RFC5656 Section 4 said that every SSH ECC implementation MUST implement ECDH key exchange. So, I was transitioning all of those MUST to SHOULD requirements. It is not clear to me if the curve25519 and curve448 KEX method would fall into the RFC 5656 MUST requirements or not. > Also, is there need to update other algorithms, i.e. encryption > algorithms, MAC algorithms, Public key names, comperssion algorithms > etc? Are the implementation requirements for them up to date (I do not > know, as I have no idea which of them are now mandatory to implement, > and which are not). Good question. I am not sure if they are all being managed by the Curdle Group or not.... I am not sure that they all belong in one document or not. It seems like it might be better for each section to have its own document specifying the MUST/SHOULD/MAY/SHOULD NOT advise... The current IANA SSH Parameters are provided in: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml 1) Encryption algorithms We have a new one comding in Curdle: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ but I do not see any drafts for SSH yet. I suspect that one or more of these encryption ciphers should be avoided (des-cbc and the arcfour* algorithms). I am not sure of the state of all of them. The SSH Encryption Algorithm Name list has the following IANA table: Encryption Algorithm Name Reference Note 3des-cbc [RFC4253] Section 6.3 blowfish-cbc [RFC4253] Section 6.3 twofish256-cbc [RFC4253] Section 6.3 twofish-cbc [RFC4253] Section 6.3 twofish192-cbc [RFC4253] Section 6.3 twofish128-cbc [RFC4253] Section 6.3 aes256-cbc [RFC4253] Section 6.3 aes192-cbc [RFC4253] Section 6.3 aes128-cbc [RFC4253] Section 6.3 serpent256-cbc [RFC4253] Section 6.3 serpent192-cbc [RFC4253] Section 6.3 serpent128-cbc [RFC4253] Section 6.3 arcfour [RFC4253] Section 6.3 idea-cbc [RFC4253] Section 6.3 cast128-cbc [RFC4253] Section 6.3 none [RFC4253] Section 6.3 des-cbc [FIPS-46-3] HISTORIC, See page 4 arcfour128 [RFC4345] arcfour256 [RFC4345] aes128-ctr [RFC4344] aes192-ctr [RFC4344] aes256-ctr [RFC4344] 3des-ctr [RFC4344] blowfish-ctr [RFC4344] twofish128-ctr [RFC4344] twofish192-ctr [RFC4344] twofish256-ctr [RFC4344] serpent128-ctr [RFC4344] serpent192-ctr [RFC4344] serpent256-ctr [RFC4344] idea-ctr [RFC4344] cast128-ctr [RFC4344] AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 2) MAC Algorithm Names has the following IANA table: MAC Algorithm Name Reference Note hmac-sha1 [RFC4253] Section 6.4 hmac-sha1-96 [RFC4253] Section 6.4 hmac-md5 [RFC4253] Section 6.4 hmac-md5-96 [RFC4253] Section 6.4 none [RFC4253] Section 6.4 AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 hmac-sha2-256 [RFC6668] Section 2 hmac-sha2-512 [RFC6668] Section 2 Of the above, I believe that hmac-sha1-96, hmac-md5-96, and hmac-md5 are considered insecure by some parties. As RFC 5647 was informational rather than standard track and does not play well with SSH negotiation of Cipher+MAC, I am not sure how to count it. Unless someone wants to play with SHA-3 (FIPS PUB 202), or revise RFC 5647, I do not see any real changes needed. 3) Public Key Algorithm Names Public Key Algorithm Name Reference Note ssh-dss [RFC4253] Section 6.6 ssh-rsa [RFC4253] Section 6.6 spki-sign-rsa [RFC4253] Section 6.6 spki-sign-dss [RFC4253] Section 6.6 pgp-sign-rsa [RFC4253] Section 6.6 pgp-sign-dss [RFC4253] Section 6.6 null [RFC4462] Section 5 ecdsa-sha2-* [RFC5656] x509v3-ssh-dss [RFC6187] x509v3-ssh-rsa [RFC6187] x509v3-rsa2048-sha256 [RFC6187] x509v3-ecdsa-sha2-* [RFC6187] 4) Compression Algorithms > -- > kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 12:57:59 2016 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 5F8C212B0F8 for ; Mon, 12 Sep 2016 12:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 d7nkgau4Cqqy for ; Mon, 12 Sep 2016 12:57:58 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 C680512B0F7 for ; Mon, 12 Sep 2016 12:57:57 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C9DDF85ED0; Mon, 12 Sep 2016 19:57:56 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B6A3285EB5 for ; Mon, 12 Sep 2016 19:57:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 Q-IdJD6kRQoh for ; Mon, 12 Sep 2016 19:57:48 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E774C85EB0 for ; Mon, 12 Sep 2016 19:57:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=dzlzDPyJF2/pSQWCI1MmEb8Ra6xMljIcP/YhKmeG8P8=; b=e6zBm7H82Z8GeikHU7FxzRxS7jL9Q4y6G2b7TTRiJREqQfuuM8h+2x4kydiwzUNZddutz+F6CMYar pxpo95cegfslS1DIR2koYrtCZISloKKlDGl4Wdb2/NoHJoR+13hKQ955/PVtVxn7NK3A7FYn7oa4za u/zFHntehDr279XDEBwavRml7a822AckbQF8wixpI+7PpCX93447wF/brmetMyQpE5Z/8rBUd4fukq fk89ICUqQyonckBU0naW5GVSnGulW/q6lpXa37/jpmNO3xGsbCBHGSfpfCP+XL2xFTjPCJ1C0wRfAS hoKc6d7FOXxF4FgadtDtkrOQt8KH+3A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 12 Sep 2016 20:57:42 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Tero Kivinen" , "Mark D. Baushke" Cc: "Curdle" , "IETF SSH" References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> <53468.1473704115@eng-mail01.juniper.net> In-Reply-To: <53468.1473704115@eng-mail01.juniper.net> Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 Date: Mon, 12 Sep 2016 13:56:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list > As RFC 5647 was informational rather than standard track > and does not play well with SSH negotiation of Cipher+MAC, > I am not sure how to count it. Yeah. :( These algorithms (AEAD_AES_128_GCM and AEAD_AES_256_GCM) really ought to be considered SHOULD NOT. The real SHOULD versions are aes128-gcm@openssh.com and aes256-gcm@openssh.com, which currently do not have a formal spec, but are defined as "what RFC 5647 says, but with reasonable rules for algorithm negotiation". We ought to make this formal by specifying new algorithm names aes128-gcm and aes256-gcm, and defining this in roughly the same way (what RFC 5647 says, but with reasonable negotiation rules). It should be identical to the @openssh.com versions, except with formally adopted names. If we want to do this, I can write up this spec. > 3) Public Key Algorithm Names > Public Key Algorithm Name Reference Note > ssh-dss [RFC4253] Section 6.6 > ssh-rsa [RFC4253] Section 6.6 This table should be expanded with another column, Signature Algorithm Name. For most algorithms, it's just a copy of the value in Public Key Algorithm Name. For ssh-rsa, however, there need to be two additional lines, for three total: ssh-rsa ssh-rsa [RFC4253] Section 6.6 ssh-rsa rsa-sha2-256 (other draft) Section 2 ssh-rsa rsa-sha2-512 (other draft) Section 2 The "other draft" in this case is the rsa-sha2 draft. I should modify that draft to update this table in this way. The current version of the draft does not suggest adding the extra column, but instead adds the new signature algorithm names in the existing Public Key Algorithm Name column, which is not fully correct (and may mislead implementers). denis ----- Original Message ----- From: Mark D. Baushke Sent: Monday, September 12, 2016 12:15 To: Tero Kivinen Cc: Curdle ; IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 Tero Kivinen writes: > That looks mostly ok. Most of the sha1 -> SHOULD NOT, with exception > to the diffie-hellman-group14-sha1 and gss-group-14-sha1-*, which are > still kept as SHOULD for backwards compatible reasons. Yes. > The MUSTs are good, but there seems to be quite a lot of SHOULD > versions. Is there really need for that many SHOULD algoritms. For > example is there reason to keep ecdh-sha2-* as SHOULD when > curve25519-sha256 will be MUST? I will move ecdh-sha2-* to MAY. The RFC5656 Section 4 said that every SSH ECC implementation MUST implement ECDH key exchange. So, I was transitioning all of those MUST to SHOULD requirements. It is not clear to me if the curve25519 and curve448 KEX method would fall into the RFC 5656 MUST requirements or not. > Also, is there need to update other algorithms, i.e. encryption > algorithms, MAC algorithms, Public key names, comperssion algorithms > etc? Are the implementation requirements for them up to date (I do not > know, as I have no idea which of them are now mandatory to implement, > and which are not). Good question. I am not sure if they are all being managed by the Curdle Group or not.... I am not sure that they all belong in one document or not. It seems like it might be better for each section to have its own document specifying the MUST/SHOULD/MAY/SHOULD NOT advise... The current IANA SSH Parameters are provided in: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml 1) Encryption algorithms We have a new one comding in Curdle: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-chacha20-poly1305/ but I do not see any drafts for SSH yet. I suspect that one or more of these encryption ciphers should be avoided (des-cbc and the arcfour* algorithms). I am not sure of the state of all of them. The SSH Encryption Algorithm Name list has the following IANA table: Encryption Algorithm Name Reference Note 3des-cbc [RFC4253] Section 6.3 blowfish-cbc [RFC4253] Section 6.3 twofish256-cbc [RFC4253] Section 6.3 twofish-cbc [RFC4253] Section 6.3 twofish192-cbc [RFC4253] Section 6.3 twofish128-cbc [RFC4253] Section 6.3 aes256-cbc [RFC4253] Section 6.3 aes192-cbc [RFC4253] Section 6.3 aes128-cbc [RFC4253] Section 6.3 serpent256-cbc [RFC4253] Section 6.3 serpent192-cbc [RFC4253] Section 6.3 serpent128-cbc [RFC4253] Section 6.3 arcfour [RFC4253] Section 6.3 idea-cbc [RFC4253] Section 6.3 cast128-cbc [RFC4253] Section 6.3 none [RFC4253] Section 6.3 des-cbc [FIPS-46-3] HISTORIC, See page 4 arcfour128 [RFC4345] arcfour256 [RFC4345] aes128-ctr [RFC4344] aes192-ctr [RFC4344] aes256-ctr [RFC4344] 3des-ctr [RFC4344] blowfish-ctr [RFC4344] twofish128-ctr [RFC4344] twofish192-ctr [RFC4344] twofish256-ctr [RFC4344] serpent128-ctr [RFC4344] serpent192-ctr [RFC4344] serpent256-ctr [RFC4344] idea-ctr [RFC4344] cast128-ctr [RFC4344] AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 2) MAC Algorithm Names has the following IANA table: MAC Algorithm Name Reference Note hmac-sha1 [RFC4253] Section 6.4 hmac-sha1-96 [RFC4253] Section 6.4 hmac-md5 [RFC4253] Section 6.4 hmac-md5-96 [RFC4253] Section 6.4 none [RFC4253] Section 6.4 AEAD_AES_128_GCM [RFC5647] Section 6.1 AEAD_AES_256_GCM [RFC5647] Section 6.2 hmac-sha2-256 [RFC6668] Section 2 hmac-sha2-512 [RFC6668] Section 2 Of the above, I believe that hmac-sha1-96, hmac-md5-96, and hmac-md5 are considered insecure by some parties. As RFC 5647 was informational rather than standard track and does not play well with SSH negotiation of Cipher+MAC, I am not sure how to count it. Unless someone wants to play with SHA-3 (FIPS PUB 202), or revise RFC 5647, I do not see any real changes needed. 3) Public Key Algorithm Names Public Key Algorithm Name Reference Note ssh-dss [RFC4253] Section 6.6 ssh-rsa [RFC4253] Section 6.6 spki-sign-rsa [RFC4253] Section 6.6 spki-sign-dss [RFC4253] Section 6.6 pgp-sign-rsa [RFC4253] Section 6.6 pgp-sign-dss [RFC4253] Section 6.6 null [RFC4462] Section 5 ecdsa-sha2-* [RFC5656] x509v3-ssh-dss [RFC6187] x509v3-ssh-rsa [RFC6187] x509v3-rsa2048-sha256 [RFC6187] x509v3-ecdsa-sha2-* [RFC6187] 4) Compression Algorithms > -- > kivinen@iki.fi _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 13:57:50 2016 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 5C3C512B127 for ; Mon, 12 Sep 2016 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 wiD8a0o_8_bx for ; Mon, 12 Sep 2016 13:57:47 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 561FC12B12C for ; Mon, 12 Sep 2016 13:57:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 1BC3485ED8; Mon, 12 Sep 2016 20:57: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 6879D85ED3 for ; Mon, 12 Sep 2016 20:57:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id geCdbHrs4GNd for ; Mon, 12 Sep 2016 20:57:31 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::707]) by mail.netbsd.org (Postfix) with ESMTP id A698F85EAB for ; Mon, 12 Sep 2016 20:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/U1EOeoSyYjPBJk4XxL7MGAvuEmBwaHzXKDMhi6MFBI=; b=eUyGKHK8HRyWIngW6FhjdH3ZG9GV8IEMZxMU06IquhMpcZuAD7EMeoEA90/CU8gC0FShmiGfF2RQKoeIhKLax8GY6s61g3LjQroejFXVSwLJhPcsyCHakyqOKyh04h8g+86xPsAPPkMd1WzWCh+UhiALHbXCm+ZBesjKkocWArA= Received: from DM2PR0501CA0033.namprd05.prod.outlook.com (10.162.29.171) by DM2PR0501MB1200.namprd05.prod.outlook.com (10.160.245.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Mon, 12 Sep 2016 20:57:28 +0000 Received: from BY2FFO11FD049.protection.gbl (2a01:111:f400:7c0c::199) by DM2PR0501CA0033.outlook.office365.com (2a01:111:e400:5148::43) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Mon, 12 Sep 2016 20:57:28 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD049.mail.protection.outlook.com (10.1.15.186) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Mon, 12 Sep 2016 20:57:27 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 12 Sep 2016 13:57:22 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8CKvKnw003290; Mon, 12 Sep 2016 13:57:20 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 3609811446; Mon, 12 Sep 2016 13:57:20 -0700 (PDT) To: "denis bider (Bitvise)" CC: Tero Kivinen , Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> <53468.1473704115@eng-mail01.juniper.net> Comments: In-reply-to: "denis bider (Bitvise)" message dated "Mon, 12 Sep 2016 13:56:56 -0600." From: "Mark D. Baushke" Date: Mon, 12 Sep 2016 13:57:20 -0700 Message-ID: <77212.1473713840@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(53416004)(15975445007)(105596002)(106466001)(19580405001)(76506005)(305945005)(47776003)(2950100001)(81156014)(11100500001)(19580395003)(69596002)(86362001)(4326007)(2906002)(8676002)(77096005)(50986999)(586003)(189998001)(97736004)(54356999)(5660300001)(92566002)(356003)(81166006)(76176999)(50466002)(93886004)(230783001)(5003940100001)(7696004)(117636001)(48376002)(87936001)(7126002)(68736007)(2810700001)(626004)(8936002)(110136003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1200;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD049;1:Z3hM5GIYRo2vWTVFF/TVZ3H57aUO6AlaWqsp2RLT2vFJEPMkdUaqiLhOxT7eVVXxLzN/dMmhu0vXzymDmJHN619oCIIXR15vPXzbmKipbmTPhU1yyOvvzjWjUq0RoOqJ637HhWkCRN4mMUkJMNd1hZaxe/eV5RkZ465x91OiPkEwHhFRzoPC5w688aiFw05FXNGhLNVzdsIy8FWwtFzZaODDFrVl+gf0YY9dJL2BryyGgGtK17ZF0KoalVW7aBc0v0Vy678nxJlJpVpcdg0tgsVGaeJB7OPMqWr1fzmkQt9gcUCj9wfaI8E7VH/snny/rPVc+OA6kf5/Vh3d99TtTo/qgABENvt7sLucwCdcuXdLMzD4VWpCBbxbK3h0ENiMTXcTQf8tq0vu/ZK532/Cs4BZGzSr7+ZKdooYBF8m1+oVf1PZufzLazqxeOQLDCZ/H42uD9ZsbGv+xQ7ecC8vULwLxy4eTIyE++DQxhL2qcyDWJ4ksdw9TF2JB70IN0LK4M6DljhmOCRBWojJroORqIJ8R/qaiMZGY+cA1+yhILrOCInjKl3JUh6wKrkQXJCp X-MS-Office365-Filtering-Correlation-Id: 5151719f-ee98-413f-c140-08d3db4f67d2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1200; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(76576733993138)(165104125076784)(65766998875637)(131022147185803); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13017025)(13015025)(13023025)(13024025)(13018025)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:DM2PR0501MB1200;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1200; X-Forefront-PRVS: 006339698F X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2016 20:57:27.7796 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1200 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list denis bider (Bitvise) writes: > Yeah. :( These algorithms (AEAD_AES_128_GCM and AEAD_AES_256_GCM) > really ought to be considered SHOULD NOT. The real SHOULD versions are > aes128-gcm@openssh.com and aes256-gcm@openssh.com, which currently do > not have a formal spec, but are defined as "what RFC 5647 says, but > with reasonable rules for algorithm negotiation". I admit I like the OpenSSH specification better myself. > We ought to make this formal by specifying new algorithm names > aes128-gcm and aes256-gcm, and defining this in roughly the same way > (what RFC 5647 says, but with reasonable negotiation rules). It should > be identical to the @openssh.com versions, except with formally > adopted names. > > If we want to do this, I can write up this spec. I think the only reason I have seen folks list AEAD_AES_nnn_GCM in requirements documents is to appease the either Common Criteria or FIPS standards. Things got odd when the NIST SP 800-38D references were put into the FIPS 140-2 Implementation Guidance in section A.5 in March 2009. It changed last year, but it is still not entirely clear how this section impacts SSH. The section provides techniques for generation an IV that are acceptable for the purpose of FIPS 140-2 validations, but only list TLS-v1.2 and IPsec-v3. Folks who want to read the current details can look in http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf Section A.5 was last modified on August 7, 2015. The NIST SP 800-38D should be found at this URL: http://dx.doi.org/10.6028/NIST.SP.800-38D (it redirects to http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38D.pdf). The 8.2.1 Deterministic Construction alternative seems to be the only one that still meets the FIPS 140-2 guidance. > > 3) Public Key Algorithm Names > This table should be expanded with another column, Signature Algorithm > Name. For most algorithms, it's just a copy of the value in Public Key > Algorithm Name. For ssh-rsa, however, there need to be two additional > lines, for three total: > > ssh-rsa ssh-rsa [RFC4253] Section 6.6 > ssh-rsa rsa-sha2-256 (other draft) Section 2 > ssh-rsa rsa-sha2-512 (other draft) Section 2 > > The "other draft" in this case is the rsa-sha2 draft. > > I should modify that draft to update this table in this way. The > current version of the draft does not suggest adding the extra column, > but instead adds the new signature algorithm names in the existing > Public Key Algorithm Name column, which is not fully correct (and may > mislead implementers). That sounds like a good plan to me. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 14:36:42 2016 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 7361A12B09F for ; Mon, 12 Sep 2016 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 HVrO7R6PTudP for ; Mon, 12 Sep 2016 14:36:40 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 78B5612B090 for ; Mon, 12 Sep 2016 14:36:40 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 9458A85ED7; Mon, 12 Sep 2016 21:36:39 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 46B9185ED3; Mon, 12 Sep 2016 21:36:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2DDE885ED0 for ; Mon, 12 Sep 2016 19:15:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 TKhjGhIGrT8d for ; Mon, 12 Sep 2016 19:15:28 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 4A5FF84CFD for ; Mon, 12 Sep 2016 19:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=9U6g2sVjtvC9XuZJHmR1WYJorC/+XDHQN6FXqXjVDnk=; b=OJ4BmlEefFVHROmsZn6rspOl3Zi13n+9jveX4IkZBzHOcEkTGdC0jmakU28n3HALtlAPeKj9E0GWb YzCpys4F173JAupSbHK1ypqAvgWHOC7SUYUc76TvJ0GUC7N75S+6FxP5DmfIUqz1WVm7YcsOUWv5vs RR4mPBmIlk9YL1NjE1NQ7ip+k+VjSk0IKSIY4I0IpiscTAX0vzxOVFqsjKf/ycn8SSTavuuPT80uhh oPFV/YgYmHM1yhoPUqIBj/dJPjpvQIefUPqAkUuFlLjnLek0+tLW5x3NoIDKi3MFSO8oSDRkMNapyI 4XeXmEpgF26VCwveIj/Nt1L6iDWGJ/g== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Mon, 12 Sep 2016 20:15:22 +0100 Message-ID: <5A3D7904D0C749668769F3F30009C436@Khan> From: "denis bider \(Bitvise\)" To: "Ron Frederick" , References: <88F8D101-CBAA-4E57-AD25-8F403B6B57BC@timeheart.net> In-Reply-To: <88F8D101-CBAA-4E57-AD25-8F403B6B57BC@timeheart.net> Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Date: Mon, 12 Sep 2016 13:14:20 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01D20CF7.928CEB90" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_003F_01D20CF7.928CEB90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Ron, I=E2=80=99m not familiar with the OpenSSH certificate implementation, = but there is an RFC specifying the use of X.509 certificates in SSH that = defines its own key type for RSA with SHA-2 based signatures: https://tools.ietf.org/html/rfc6187 I don=E2=80=99t know what your users require, but from our users we are = seeing requests to implement X.509 as per this RFC, not the @openssh = versions. denis From: Ron Frederick=20 Sent: Sunday, September 11, 2016 20:39 To: ietf-ssh@netbsd.org=20 Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding Denis Bider (Bitvise) wrote: If you are sending an rsa-sha2-XXX signature, you cannot set all 3 = fields in the authentication request to "ssh-rsa", because then this = makes for a SHA-1 signature as it was done traditionally, not a SHA-2 = signature. To send a SHA-2 signature, at least one field has to contain = "rsa-sha2-XXX". The draft specifically says the signature format names are = "rsa-sha2-XXX", but the public key format name stays "ssh-rsa", which it = must stay in order to preserve existing RSA key fingerprints. The signature format is defined thus: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob These specifications seem to me very clear and unambiguous. In a user = authentication request, when sending a SHA-2 signature, the only correct = encoding of algorithm names is as follows: byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string "rsa-sha2-256" / "rsa-sha2-512" string public key blob: string "ssh-rsa" mpint e mpint n string signature: string "rsa-sha2-256" / "rsa-sha2-512" string rsa_signature_blob If your implementation does not encode the algorithm names this way, = it is incorrect. The latest OpenSSH versions encode the algorithm names = this way, though a previous version used "ssh-rsa" in the third field by = mistake. Bitvise SSH Client encodes the fields this way also, and the current = version of Bitvise SSH Server expects the algorithm names this way, and = only this way. I did an implementation of this recently for AsyncSSH, and I have = matched the above in the case where regular keys are used, with the = first and third identifiers being rsa-sha2-256/rsa-sha2-512 and the = second identifier remaining ssh-rsa when the new-style signatures are = used. However, I also wanted to verify the correct identifiers to use in = the certificate case. Right now, I=E2=80=99m using ssh-rsa-cert-v01@openssh.com as both the = first and second identifier in the certificate case, and only using = rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the = signature. This seems to work when talking to an OpenSSH server, and in = fact OpenSSH doesn=E2=80=99t seem to accept the certificate if the first = identifier does not identify that a certificate is being used, even if = the second identifier indicates that a certificate was provided as the = public key blob. I know that certificates are OpenSSH-specific, so my apologies in = advance if this is the wrong list to ask this question on. I just = happened to see this thread in the mailing list archive, and though it = would be good to get confirmation from the group. --=20 Ron Frederick ronf@timeheart.net ------=_NextPart_000_003F_01D20CF7.928CEB90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello Ron,
 
I=E2=80=99m not familiar with the OpenSSH certificate = implementation, but there is=20 an RFC specifying the use of X.509 certificates in SSH that defines its = own key=20 type for RSA with SHA-2 based signatures:
 
 
I don=E2=80=99t know what your users require, but from our users we = are seeing=20 requests to implement X.509 as per this RFC, not the @openssh = versions.
 
denis
 
 
Sent: Sunday, September 11, 2016 20:39
Subject: Re: rsa-sha2-256/512: handling of incorrect = signature=20 encoding
 
Denis=20 Bider (Bitvise) wrote:
If you are sending = an=20 rsa-sha2-XXX signature, you cannot set all 3 fields in the = authentication=20 request to "ssh-rsa", because then this makes for a SHA-1 signature as = it was=20 done traditionally, not a SHA-2 signature. To send a SHA-2 signature, = at least=20 one field has to contain "rsa-sha2-XXX".
 
The draft = specifically says=20 the signature format names are "rsa-sha2-XXX", but the public key = format name=20 stays "ssh-rsa", which it must stay in order to preserve existing RSA = key=20 fingerprints.
 
The signature = format is=20 defined thus:
 
  string    "rsa-sha2-256" /=20 "rsa-sha2-512"
  string   =20 rsa_signature_blob
 
These = specifications seem to=20 me very clear and unambiguous. In a user authentication request, when = sending=20 a SHA-2 signature, the only correct encoding of algorithm names is as=20 follows:
 
byte     =20 SSH_MSG_USERAUTH_REQUEST
string    user name
string    service = name
string    "publickey"
boolean   TRUE
string    "rsa-sha2-256" / = "rsa-sha2-512"
string    public key = blob:
  string   =20 "ssh-rsa"
  mpint     = e
  mpint     = n
string    signature:
  string    = "rsa-sha2-256" /=20 "rsa-sha2-512"
  string   =20 rsa_signature_blob
If your = implementation does=20 not encode the algorithm names this way, it is incorrect. The latest = OpenSSH=20 versions encode the algorithm names this way, though a previous = version used=20 "ssh-rsa" in the third field by mistake.
 
Bitvise SSH Client = encodes=20 the fields this way also, and the current version of Bitvise SSH = Server=20 expects the algorithm names this way, and only this = way.
 
I did an = implementation of this=20 recently for AsyncSSH, and I have matched the above in the case where = regular=20 keys are used, with the first and third identifiers being=20 rsa-sha2-256/rsa-sha2-512 and the second identifier remaining ssh-rsa = when the=20 new-style signatures are used. However, I also wanted to verify the = correct=20 identifiers to use in the certificate case.
 
Right now, = I=E2=80=99m using ssh-rsa-cert-v01@openssh.com= as=20 both the first and second identifier in the certificate case, and only = using=20 rsa-sha2-256/rsa-sha2-512 for the third identifier associated with the=20 signature. This seems to work when talking to an OpenSSH server, and in = fact=20 OpenSSH doesn=E2=80=99t seem to accept the certificate if the first = identifier does not=20 identify that a certificate is being used, even if the second identifier = indicates that a certificate was provided as the public key blob.
 
I know that = certificates are=20 OpenSSH-specific, so my apologies in advance if this is the wrong list = to ask=20 this question on. I just happened to see this thread in the mailing list = archive, and though it would be good to get confirmation from the = group.
--
Ron Frederick
 

 
------=_NextPart_000_003F_01D20CF7.928CEB90-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 17:58:05 2016 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 54B0C12B04A for ; Mon, 12 Sep 2016 17:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 xT9zjSEnkEA6 for ; Mon, 12 Sep 2016 17:58:04 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 3A38C12B03F for ; Mon, 12 Sep 2016 17:58:04 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id AFB3285ED2; Tue, 13 Sep 2016 00:58:02 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D440685EB0 for ; Tue, 13 Sep 2016 00:57:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 SXn0G-TK9a1T for ; Tue, 13 Sep 2016 00:57:58 +0000 (UTC) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::723]) by mail.netbsd.org (Postfix) with ESMTP id E7E8F84CED for ; Tue, 13 Sep 2016 00:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B1xAwguZUkXKsuIJbSN5HmhOrDmRufgt8vEnjXfDxKA=; b=fqPbM49lOU+jD8jTcr0mkdFcq0DUKuqfk0KKmoszHJuHpUftT0u5mRwi+NYEZKosDpTt2Z5PGPRWVzh7KJkM7NqjPf7USyviUvcbFZyLGRa2myonq51wTyaj3AgFjnfMgsNYLNLrjkY8MqwhRe8JMqSykPRomN3bPjkTajqQ+ks= Received: from SN1PR0501CA0033.namprd05.prod.outlook.com (10.163.126.171) by SN2PR0501MB991.namprd05.prod.outlook.com (10.160.17.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.609.3; Mon, 12 Sep 2016 04:09:15 +0000 Received: from BY2FFO11FD005.protection.gbl (2a01:111:f400:7c0c::134) by SN1PR0501CA0033.outlook.office365.com (2a01:111:e400:52fe::43) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Mon, 12 Sep 2016 04:09:15 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Mon, 12 Sep 2016 04:09:15 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 11 Sep 2016 21:09:15 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8C49ETu009706; Sun, 11 Sep 2016 21:09:14 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id F405C1141B; Sun, 11 Sep 2016 21:09:12 -0700 (PDT) To: Curdle CC: IETF SSH From: "Mark D. Baushke" Subject: draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 Date: Sun, 11 Sep 2016 21:09:12 -0700 Message-ID: <41049.1473653352@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(9170700003)(626004)(8936002)(86362001)(19580395003)(15975445007)(586003)(92566002)(54356999)(7126002)(77096005)(50466002)(50986999)(230783001)(81166006)(5660300001)(356003)(2906002)(106466001)(7696004)(2810700001)(4326007)(76506005)(117636001)(229853001)(48376002)(305945005)(189998001)(5003940100001)(47776003)(11100500001)(53416004)(87936001)(105596002)(4001520100001)(110136002)(8676002)(5001760100003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:SN2PR0501MB991;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11FD005;1:+KoJT0Of18VtveoNQXAYaPnrB6j+Zt7kFM1nPN23ZmI02SNlDHKMoI/9j95MOR6hpbXpN7pdqbBRNEyLFuQn95CppQEWMfnOo1KQuHyul2vbQR4PNObTXeScz5auzpzrefkKQ/KeYxUsoIg/5uts2hXWZB9iuSXk1pflZDXeqJSr0cQwfO1QcVPI+PHVlEhJoZEuC+RONOozV+ysUuztb9nnifZhTH19viGZ5FmXP46I9kByzI2Z30KBiJ2hvNbb1BKR+qkiGyX0LmdNOxyMEoQG65eT7FZ1W/CsEkMZlWoFxEWypcGaY3tNUq6iv1KIPbuWCaXbihXMy4ypmSr+9w+RWdwF42XJw5sc6CqmzzfUG9e5UFG3SllMyJCcs0aBGjbKmyh2/SFM3Y/nQ+NV7uoOlz4F+VNGs2b5auNq7N0h7YlrjOdDsldl9J9WenfS8J28Zt7sNUmao3jSfZJu2fCLAQsjTCfgxC3GMfuCh1B76bxb1rSGt/lSQAybGY5gTJLbPu3egbc0NqxG/aZwBS6kIGvfYL3HKzy8GLgd5+s= X-MS-Office365-Filtering-Correlation-Id: 70968944-9e68-4965-ad2e-08d3dac28f8f X-Microsoft-Exchange-Diagnostics: 1;SN2PR0501MB991;2:ABjRQdT59axHFFaOQX/aqfH3+7XS7Oin22vl8i76WgCLLPiJCJq+xzgHGCSmkOk/rc9mvhBG+PmPmzlV0rPtgF9oE5QzzNGKFVqxCx4b/zanl04VbMtw7GnxYxDzHD0Dx7M9e8KX4KlpguIXupaNW66g1ulBbXzDfpGfyjgJzLW6kVrsfU2HAyUDjfWJR6DT;3:EJOseA2EctiBkGOGlPSyMi+A6xVJU2VUjjpiWWAw+WX1kIFRpbBmTdQL+teTvlSoci9iPXXN+0CyIk/PywJtGzNKdppNhsf4dx9y73IOYBQ3ZusOeMWiX6Y4uBhSasKAlQAwLQKIo153QoTvMlfOLZsaU8ZOi4QxPnHJLQciADj04I/5lTgVY7gT6d9hU5xM6VSzcwMFT+GNXSewGTeJoAZWIMVdsdR9UQFPriCM/zk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB991; X-Microsoft-Exchange-Diagnostics: 1;SN2PR0501MB991;25:7HeRZ+AkO67r1bHzu8JG6Wkkg+6sug6omsnjKc/jNN6C9yMB4kKQtAXx6SnQs2sEQnONc6mZV0ED2UNGH/SD0kywiW0HyalVsJ6SIV0VZZ7LAeDP/d4P8pHJXWOz7dP3Mhz7ArNnRPkPqx7nNhqUWfu1SpL13Z2Sj/ZhiOETQhg4AuGACQmRuXezOhhBue+p6SK8YrKv6ZQeNUk5OxzN4MvoQswJCIMkHrdy0uAoEn2CH0haK0judbSg2JrkjNFNozAB9/ImTcDFChqfsx+AE0rFXoAJK6NeqYXdK/hNwjYVbIMIyrkMYvrfglWR8QS7EovJDGgfgUumx+h2Bo8qbd0X6tBlS2PnchHk1ifESBoCSKYkyyYZNf8sQDUdD9pbGkiVKewaMhfU5UkspLoAX+1lfKxon3umG8cwEWIN/uJ5U5efeanumJvDqKrQ2p3XbB4O3OjMzFqmPvWY+T9NFH8PFBcUAjgpg34JojuxsOWMHIDL6RGe++K6aJWqS9YnQJ8CGK0lMyZhCc7DLASUT+HtxWQ1g5EGpgGkuefgfRoGsDq5ltJEB7zEanPJmr6ppaiarApu2CKpL9+Z8040IiixQrpxIFK+i/lNt2oc7dI4Y9aNTGCTfIpGzk+nYO6yuBJ/X5BN0qjBMj31cRfgQE+uVOWtTyyHtJsnGxrMfOZMJkjaki98gHKfznwvxhW4Pt8IQnmzlwTparZR1LIrM6QPLYl2F+EwB3ln5Kq3UhlkEXlES37STIoYwxt69rhISNhnBA8d46erKDghRecIxPj8rFrNgiWQBmh7vA4ajJzzXEgkYDORdf+j8IgHJu7qPK1BY5FKpzj/CMkrT1MvWPPvvByPB4Zs617jZg+sjxk= X-Microsoft-Exchange-Diagnostics: 1;SN2PR0501MB991;31:BqSiZgZzJNgOFUUei4GiKMivqn++vQy4F45cwvVr/Mzb1c/Vt+T0FmBVuM+cvgxZrr+0uyai50wSW3KmkIUc8U4yEVIe2CAQQutF+jT6Bt8fnGluu9uWUUJGepU5mgVqKl9gPhzG3gE9tKWIu/Lcc/PtGN4PdcChpHcuf6pTqeyoeN04sCLEGj8z+ETgn2xqjDvF+CRXVAquT0MdTwkyDX1JJyHV8lOS71cAlKgtpmw=;20:3JupKz19ez6h2OYHv+PoQd2iPAfk3kD1R8+dxG9cHIyOnBCaFvqT2vdItlA+ZkWglDzZlr9OzhQg61BEwa0M+ZYYxzk0DissRBpsOqPhdUtCK/Ualdy+VCANZo7eV30fP3IAe359v3lvt24Z1eSkp1FMXwFeeN/W2ufVR1o+PEXlNtA6MIZmg38fveoAaRSVVWW9+0l82X1jc1gpSU5A3sioLx8XfnaweXhMQymDGBB4tXqpA4p7vIBlbyoCl8DUtSdotRpesjx3PocPlNcy2VhbDVASFO2RY04AetMaVcEJbZBQY5jSSd18ZWGIQYIw0Ru0JgdiN4ukeEEMxD3XtERVn7GX8rz28JXDyhgdJCMtsCwrFhRzJtwYwp84PWfn4fz2U8PoZYhF6Ejjgzqttil8w//+Aa9mbd/AqT3a83V3ADrw/oh1LJuphwO3Rbns8HQY9axAO67bosfv2salyTGljwdx5VQu4Jsym0vDckdmu2HqnRv0GMnCJgk6OOCR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13015025)(13017025)(13023025)(13024025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:SN2PR0501MB991;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0501MB991; X-Microsoft-Exchange-Diagnostics: 1;SN2PR0501MB991;4:fiWVjpRw5GtQHipdtS+p8a0xjbMn27u9yrTC1g6OppJQIoS6DxYr65eipXThUef6fY+km1PzQoQCZoOD/jlztz15HeKtDsUUzfOGR2gEXXlfpie80BVOoM9PjpwmqMkLk/3wO5mOVRE5Cm2EUIl06JKr8erHo3QMwg3xbzIwCCBv6Bb83L1aBKgMjf+KsCspM6apTY0LWIif9Snd9rqtO2Ce+4HYz1YwU3TO3PG8Ale/7mX/6l9+ekQxMNUzfkXGOQr601RzjTSEeSiPI8Bhv8AVrDsizrSu6aaWbVBK2QsBckg0eeKJJ+O9DJkyVxPtz0u0CSVzSLuYPDuq4ZFLoRgeC1PLvVPkfEaTq8YGgEgenUFX90F0IGBsMOdv6eQ0OJzPXePxKIiTBTuh9vPCBPQk1iFs3XRNgzXXouqCYqlq/QFdVqrv8JhLdKfjkNaJ0ecehJNkpZBFNaF4F1YYoVy8ziv8ZmsEQAbEb0LbF8E/IVwr4upLhXYVWjyLd3Vn X-Forefront-PRVS: 006339698F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN2PR0501MB991;23:uzqEZ/8eSdCzOc/7uaEPj2/y+/13sCGZ7rTzkZII?= =?us-ascii?Q?frHbv08ez/u4vb9ywihFDOqr6BGTULDB6IKd1AF/v+iUazvCv+QDAqqQz8jx?= =?us-ascii?Q?w5MYdcljm3GiM7WdPyuMvTZvbpYidM2xU6Q2OdhdC1hL4QvsxtBPD0SlAYIX?= =?us-ascii?Q?Yg7+J4wMzuzudXN23Sy/95RffNuOBJhw+/B+Je8S1BYNH1mR7CEbheT43gDq?= =?us-ascii?Q?mFGNV2JFQnAedRG2piAHCss5Vo+JmBsPJDuuIo07V1YFANt3gJ7u2gGyaUco?= =?us-ascii?Q?Z7xMbF1SZHBjsaJ0PjpSHYHIoezxhQ27EDSfw0YqFo2mHCorTA8B11BDRY8L?= =?us-ascii?Q?apzL3t1DH0Eh408f3iD5CeDHlDBx4nk6friPzJ8vs9552NPURRX2bXvX2kHD?= =?us-ascii?Q?ftc3PMyUOMdQObxGfmlZKdpF6sxIwS6rxyOD6zr0L+VtYw0stGpqQ68wJ0nf?= =?us-ascii?Q?3s9+wl21+NqVee3qZ6hsm8WAlp7QDGET9byryt7q2GE1j/XEMlMe3sQYrdPh?= =?us-ascii?Q?pHEVSmVnD1Vn0Ibjq0VoU01WjGPpntbocVhdFkgReDn4NTldCXcPpyxbBK2Q?= =?us-ascii?Q?hbDgpGvkI135dRfdlzorB0OFlGMLl41K/UtEc367ar1smAlIO6Z9ZCYJLMFj?= =?us-ascii?Q?VOeEUpuw1h/Fu7sOjT0QmmfgS7NDcrmU4vGCT65WaqDqwVI6+q9kAZyQajiw?= =?us-ascii?Q?KV9sYtrWQ2CuToPQcToydNbSv3HqFZ5ETLyPJrDtkt2nd0Y72RMQaGW+9H0q?= =?us-ascii?Q?TD/eEcUPPpsn0VQvHcP+a6mI9A+1JY4/KZzAzchB06e00+Pyk7GQ+MxRBqRk?= =?us-ascii?Q?syW707no9j6Fe8jP6UYL3c3X+/mJt7hhBtK7He1IvghYajmZhwbLF2f1633k?= =?us-ascii?Q?QLjSb7izn/nND0CRo9jXT4DmqRI8AwyFa+0URH6lOrdbJIueBI2tAhlQfmUL?= =?us-ascii?Q?M6JSMmMbSJFI2e/d076fBWXp+AsvujEOIIElmF301KwrJo+yuMCkAWDSODsj?= =?us-ascii?Q?Zf/dqyWXGXYjYnkIiTzLcuKij1W0cYF0pqnXWhbHxcxRHMXMWqLu+2ZtpRr/?= =?us-ascii?Q?gdnSjtachyLjCooQO5U9+pCB0XYlAsQRbm4R3BFL08df9pAW+Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN2PR0501MB991;6:NloFtWRHpIvVoGtOmlyVlXfr+Ct1sLNbG1PGiskOUpBT/zxeFZuoZISh09TsBNHKxn78mYrLo0Ogmvd860iUpVk5qZxgfL6TGDsNVyXIO8RSIjatIN/3Ly5CJMzyz7MJthMK64lU2aRBj8tyI/el69tp8H0h10Gbbr+9F+7AK8xGkS31620WHx1Wq7byOVIaM6Nk52IQf9Wkhv+ozEgj99GodJLX/0Q4gFSQ98tByoaROX0ClTHjtON5xW0pNgugawqxru4Yjntqbpg0Ygs5XN3xVHL+aUGoK+Fu00PjqQWpvSc8e8ihfVvH2qgERcE38aeN01MaGj/TWzVKAXgGlQ==;5:wCVHWBae8UNUbL/fqOqQqUn5QXN0i1OivrjkHKiaoROgv2091Yvw796aDy3GRU/gGnbAVebmrgdVQDMcr2yV27NPA2S044/d77Egt/ZOnjJaBUefJIiTb6rW/Pr3Z2SFW8dTEdOFPD4iuMpwSIty/Q==;24:cIzgMESz8V8jgS/qnvuMG6d3yoTW4yGNmfouRI7ElLXitDTYmDsPpQj0ehqjoCgPk9O3w6YI5oZjCjASWDUO2I2sR/ItsTyeCGl892tVDv0=;7:j7DLxUTcT/eyIt7/t3Wn6Oa83WTQ1rZYog/UhUri6KFxmyfXbmSp1BijdU0NbU6cLgr1wuUOSTJYI7seu0gGfmgZI4zlksqrTeEgdWjZZR//bYZpNr+6LioYMrb1ybznHBtPQg/o+ppfVZR43fikWcNXjOBNTQ2kstzrkYMuUduApAY6RiDzkG3sQv5hq1WoerAGqVwtiJOrc1RaN8T0yQzZAPMvorVMHT1fL1HoeWoOFrBCfYK+3SGOuFe6tsyQ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2016 04:09:15.4100 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB991 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list I have split out a new draft draft-ietf-curdle-ssh-modp-dh-sha2 [1] (called "new-modp" in the Reference table below) forked from the draft-ietf-curdle-ssh-kex-sha2-04 draft. It specifies the new MOD DH KEX Groups that use SHA-2 hashes. This edition specifies both the new diffie-hellman-group* names of the -04 revision as well as adding the gss-group* names. Before I update draft-ietf-curdle-ssh-kex-sha2-05 to point to it, I would like to take a straw poll of which algorithms (if any) should be defined as a MUST to implement. My personal preference was just curve25519-sha256. However, at least a few implementors have said that they were not planning to do any ECDH implementations. So, I am guessing that "diffie-hellman-group14-sha256" may be the only one that everyone might be able to agree is a MUST to implement. Key Exchange Method Name Reference Note curve25519-sha256 ssh-curves MUST curve448-sha512 ssh-curves MAY diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group15-sha512 new-modp MAY diffie-hellman-group16-sha512 new-modp SHOULD diffie-hellman-group17-sha512 new-modp MAY diffie-hellman-group18-sha512 new-modp MAY ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp521 RFC5656 SHOULD ecdh-sha2-* RFC5656 MAY ecmqv-sha2 RFC5656 MAY gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha1-* RFC4462 SHOULD gss-group14-sha256-* new-modp SHOULD gss-group15-sha512-* new-modp MAY gss-group16-sha512-* new-modp SHOULD gss-group17-sha512-* new-modp MAY gss-group18-sha512-* new-modp MAY gss-* RFC4462 MAY rsa1024-sha1 RFC4432 SHOULD NOT rsa2048-sha256 RFC4432 MAY I plan to post the above table in the new draft-ietf-curdle-ssh-kex-sha2-05 draft after 05:00 UTC on 12 September 2016. Of course, everyone can still lobby for changes with the Curdle group, I just don't want to generate a huge number of revisions if possible. Thank you, -- Mark URL: [1] https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-00 From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Mon Sep 12 22:57:31 2016 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 368A512B1F6 for ; Mon, 12 Sep 2016 22:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 0YTDmNWT67wW for ; Mon, 12 Sep 2016 22:57:28 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 14E5C12B1F1 for ; Mon, 12 Sep 2016 22:57:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id EF18485EDF; Tue, 13 Sep 2016 05:57:26 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 940F285EDF; Tue, 13 Sep 2016 05:57:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 482C485ED3 for ; Tue, 13 Sep 2016 03:34:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net 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 gSQN4wDKfRK4 for ; Tue, 13 Sep 2016 03:34:05 +0000 (UTC) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DD5C085ED1 for ; Tue, 13 Sep 2016 03:34:04 +0000 (UTC) Received: by mail-oi0-x235.google.com with SMTP id q188so241262206oia.3 for ; Mon, 12 Sep 2016 20:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=wS3aUnx/MajUsYqbdkL8qfEvcq5/TR6pIVtjQeKm13w=; b=GVRy1L6kFsUD0hq2B67dc4yWtbyWSpb4tKc1JmRIJJHVN57HgRS9HMulWkr/K+kzbs TCygRPJpRBk+Cbs5mESk6ZCTZau+CxOx3TDPBBaB+O4oud2jThWYP7CzxcfFFfiBeTrF HGAR2+maMgPkvdi2Y6Ux5bvH219JqZnVm0AII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wS3aUnx/MajUsYqbdkL8qfEvcq5/TR6pIVtjQeKm13w=; b=hD/9edx7JKi4yNjGjpUDz0gUc1O+0dVmadXF3ITnoZj0xJdAnHyAUH/NfvzIpD76QY PIWUvIYTQKiM11S7xLRgETL3RuJibYhPHrHEWL7wqcsumn478ww7/M504h6LDhzfl0Mh DzM/RQuZpXouUaB5+Vv1AOutSMzR12D7rhymQ1sRJpBPU50TUUK5veGAjW7YIUjYBHWI jkdc11Bv5odiUxeSQBdFcCBMXpjVCLkveuiDRIafMztzSRVfmT4rMsrknDJCnQvZ5+dd M8DRflARaL48SgngUZA6GdsAtO/TxSXoqztV6WVQOWfyNJbFSBbIagrlTxmH2RxQPt63 QXgQ== X-Gm-Message-State: AE9vXwNaafEZ/Rymb3p4Ck6orcjrxhBzxyOLJsDSNVhHLhx/xJYNyp3sSCSTM7ZmcARGwA== X-Received: by 10.202.87.76 with SMTP id l73mr3813274oib.84.1473737643700; Mon, 12 Sep 2016 20:34:03 -0700 (PDT) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id g78sm10645785itb.12.2016.09.12.20.34.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 20:34:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_581A0F77-2E96-4537-ABB6-F770CE2B0E53" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3225\)) Subject: Re: rsa-sha2-256/512: handling of incorrect signature encoding From: Ron Frederick X-Priority: 3 In-Reply-To: <5A3D7904D0C749668769F3F30009C436@Khan> Date: Mon, 12 Sep 2016 20:34:00 -0700 Cc: ietf-ssh@netbsd.org Message-Id: References: <88F8D101-CBAA-4E57-AD25-8F403B6B57BC@timeheart.net> <5A3D7904D0C749668769F3F30009C436@Khan> To: "denis bider (Bitvise)" X-Mailer: Apple Mail (2.3225) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_581A0F77-2E96-4537-ABB6-F770CE2B0E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 12, 2016, at 12:14 PM, denis bider (Bitvise) = wrote: > I=E2=80=99m not familiar with the OpenSSH certificate implementation, = but there is an RFC specifying the use of X.509 certificates in SSH that = defines its own key type for RSA with SHA-2 based signatures: > =20 > https://tools.ietf.org/html/rfc6187 = > =20 > I don=E2=80=99t know what your users require, but from our users we = are seeing requests to implement X.509 as per this RFC, not the @openssh = versions. [Ron] Thanks, Denis. I have looked at that RFC, and have thought about = adding support for both those and the OpenSSH variants. For deployments = where this is already a good X.509-based public key infrastructure in = place, I can definitely see the value in being able to use a common set = of certificate authorities for both SSL/TLS and SSH. That said, there are some challenges with supporting RFC 6187: - Parsing X.509 certificates is extremely complex, and validating a = certificate chain is even more so. If you want to do it right, you need = to bring in a bunch of additional crypto infrastructure, like support = for CRLs and OCSP. - The RFC provides a recommendation for how to validate server names = when certificates are used for host authentication, but for user = authentication it simply says "the mapping between certificates and user = names is left as an implementation and configuration issue for = implementers and system administrators.=E2=80=9D It also really = doesn=E2=80=99t provide any guidance about how to specify the list of = trusted root CAs for either user or host authentication. - While the RFC does provide a way to indicate if an X.509 certificate = can be used for user or host authentication, it doesn=E2=80=99t = currently define any way to put restrictions on when a user can use a = particular certificate or what they can do when they authenticate with a = particular certificate. This would not be difficult to do in X.509, but = I haven=E2=80=99t seen a proposed spec for encoding any such = restrictions. OpenSSH certificates addresses these points pretty well: - All parsing is done using the same mechanism used for parsing other = SSH packets, just like OpenSSH-format keys. There=E2=80=99s no need to = pull in an ASN.1 parser or deal with the large number of OID values that = need to be understood to properly parse X.509 certificates. - Specifying the list of trusted CAs and revoked certificates is done as = a natural extension of the existing authorized_keys and known_hosts file = formats. - OpenSSH provides very rich ways of limiting when certificates can be = used and what actions can be taken by a user presenting a certificate. = This can be done in either the authorized_keys file on the host deciding = whether to accept a certificate or in the certificate itself, such that = the limitations automatically apply to all hosts the certificate is = accepted on. There are some ways in which OpenSSH is behind, though: - There=E2=80=99s no support for certificate chaining. It only supports = direct signing of keys by a root CA, with no intermediate CAs. For many = organizations, I imagine this would be a show-stopper. - While it can support the equivalent of CRLs for revocation, there=E2=80=99= s currently nothing in OpenSSH equivalent to OCSP for real-time = revocation checking. If you=E2=80=99re interested, more info on OpenSSH certificates can be = found at = http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOC= OL.certkeys?rev=3D1.10&content-type=3Dtext/plain = . --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_581A0F77-2E96-4537-ABB6-F770CE2B0E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 12, 2016, at 12:14 PM, denis bider (Bitvise) <ietf-ssh3@denisbider.com> wrote:
I=E2=80=99m = not familiar with the OpenSSH certificate implementation, but there is=20= an RFC specifying the use of X.509 certificates in SSH that defines its = own key=20 type for RSA with SHA-2 based signatures:
 
https://tools.ietf.org/html/rfc6187
 
I don=E2=80=99t know what your users require, but from = our users we are seeing=20 requests to implement X.509 as per this RFC, not the @openssh = versions.

[Ron] Thanks, Denis. I have looked at that RFC, = and have thought about adding support for both those and the OpenSSH = variants. For deployments where this is already a good X.509-based = public key infrastructure in place, I can definitely see the value in = being able to use a common set of certificate authorities for both = SSL/TLS and SSH.

That said, there = are some challenges with supporting RFC 6187:

- Parsing X.509 certificates is extremely complex, = and validating a certificate chain is even more so. If you want to do it = right, you need to bring in a bunch of additional crypto infrastructure, = like support for CRLs and OCSP.

- = The RFC provides a recommendation for how to validate server names when = certificates are used for host authentication, but for user = authentication it simply says "the mapping between certificates and user = names is left as an implementation and configuration issue for = implementers and system administrators.=E2=80=9D It also really = doesn=E2=80=99t provide any guidance about how to specify the list of = trusted root CAs for either user or host authentication.

- While the RFC does provide a way to indicate if = an X.509 certificate can be used for user or host authentication, it = doesn=E2=80=99t currently define any way to put restrictions on when a = user can use a particular certificate or what they can do when they = authenticate with a particular certificate. This would not be difficult = to do in X.509, but I haven=E2=80=99t seen a proposed spec for encoding = any such restrictions.

OpenSSH = certificates addresses these points pretty well:

- All parsing is done using the same mechanism = used for parsing other SSH packets, just like OpenSSH-format keys. = There=E2=80=99s no need to pull in an ASN.1 parser or deal with the = large number of OID values that need to be understood to properly parse = X.509 certificates.

- Specifying the = list of trusted CAs and revoked certificates is done as a natural = extension of the existing authorized_keys and known_hosts file = formats.

- OpenSSH provides very = rich ways of limiting when certificates can be used and what actions can = be taken by a user presenting a certificate. This can be done in either = the authorized_keys file on the host deciding whether to accept a = certificate or in the certificate itself, such that the limitations = automatically apply to all hosts the certificate is accepted = on.

There are some ways in which = OpenSSH is behind, though:

- = There=E2=80=99s no support for certificate chaining. It only supports = direct signing of keys by a root CA, with no intermediate CAs. For many = organizations, I imagine this would be a show-stopper.

- While it can support the equivalent of CRLs for = revocation, there=E2=80=99s currently nothing in OpenSSH equivalent to = OCSP for real-time revocation checking.

If you=E2=80=99re interested, more info on OpenSSH = certificates can be found at http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin= /ssh/PROTOCOL.certkeys?rev=3D1.10&content-type=3Dtext/plain.
=
-- 
Ron = Frederick
ronf@timeheart.net



= --Apple-Mail=_581A0F77-2E96-4537-ABB6-F770CE2B0E53-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 11:56:28 2016 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 979A112B02E for ; Tue, 13 Sep 2016 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 hr8LjaZBEu0B for ; Tue, 13 Sep 2016 11:56:26 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 889F612B054 for ; Tue, 13 Sep 2016 11:56:26 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id A785285EC2; Tue, 13 Sep 2016 18:56:25 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D55D985EB3 for ; Tue, 13 Sep 2016 18:56:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id b4ZKw7QTF6v2 for ; Tue, 13 Sep 2016 18:56:22 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id D01FF85EAB for ; Tue, 13 Sep 2016 18:56:21 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8DHlLbu044848; Wed, 14 Sep 2016 03:47:22 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8DHlLYM063728 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Sep 2016 03:47:21 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u8DHlLsw020734 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Wed, 14 Sep 2016 03:47:21 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id EA78CA4F32; Wed, 14 Sep 2016 03:47:20 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id E5ED9A4F2E; Wed, 14 Sep 2016 03:47:20 +1000 (AEST) Date: Wed, 14 Sep 2016 03:47:20 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: Curdle , IETF SSH Subject: Re: draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <41049.1473653352@eng-mail01.juniper.net> Message-ID: References: <41049.1473653352@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1473788842 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Sun, 11 Sep 2016, Mark D. Baushke wrote: > I have split out a new draft draft-ietf-curdle-ssh-modp-dh-sha2 [1] > (called "new-modp" in the Reference table below) forked from the > draft-ietf-curdle-ssh-kex-sha2-04 draft. It specifies the new MOD DH KEX > Groups that use SHA-2 hashes. This edition specifies both the new > diffie-hellman-group* names of the -04 revision as well as adding the > gss-group* names. > > Before I update draft-ietf-curdle-ssh-kex-sha2-05 to point to it, I > would like to take a straw poll of which algorithms (if any) should be > defined as a MUST to implement. My personal preference was just > curve25519-sha256. However, at least a few implementors have said that > they were not planning to do any ECDH implementations. So, I am guessing > that "diffie-hellman-group14-sha256" may be the only one that everyone > might be able to agree is a MUST to implement. I agree with your choice in MUST. Two other nits: > Key Exchange Method Name Reference Note > curve25519-sha256 ssh-curves MUST > curve448-sha512 ssh-curves MAY > diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT > diffie-hellman-group-exchange-sha256 RFC4419 MAY > diffie-hellman-group1-sha1 RFC4253 SHOULD NOT > diffie-hellman-group14-sha1 RFC4253 SHOULD > diffie-hellman-group14-sha256 new-modp MUST > diffie-hellman-group15-sha512 new-modp MAY > diffie-hellman-group16-sha512 new-modp SHOULD > diffie-hellman-group17-sha512 new-modp MAY > diffie-hellman-group18-sha512 new-modp MAY > ecdh-sha2-nistp256 RFC5656 SHOULD > ecdh-sha2-nistp384 RFC5656 SHOULD > ecdh-sha2-nistp521 RFC5656 SHOULD > ecdh-sha2-* RFC5656 MAY > ecmqv-sha2 RFC5656 MAY Has anyone ever implemented this? AFAIK the motivation for this was MQV being included in NSA Suite B at the time, but it was subsequently dropped. IMO if nobody is using it then it should be recommended against. I.e. SHOULD NOT > gss-group14-sha1-* RFC4462 SHOULD > gss-group14-sha256-* new-modp SHOULD IMO these two should be MAY. Most implementations don't support GSSAPI key exchange at all. Thanks for your patience in wrangling this. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 12:23:06 2016 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 73F5012B4F2 for ; Tue, 13 Sep 2016 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 2hQ5VSgFOIE7 for ; Tue, 13 Sep 2016 12:23:05 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 42D1712B056 for ; Tue, 13 Sep 2016 12:23:05 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 10C0885EC8; Tue, 13 Sep 2016 19:23:04 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id EA6DE85EC5 for ; Tue, 13 Sep 2016 19:23:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 8U1JAS_diNSe for ; Tue, 13 Sep 2016 19:23:00 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E622F85E25 for ; Tue, 13 Sep 2016 19:22:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2RQSMdU0QT44vXK0/VG0g02w2/lN/EEt+e6ZuQzJHTU=; b=SJDMw4QUyf7shjMfJe5/lFW+/oI1VroUPHp5zGrmuZajBTuGigcEGLYoz+DFVFOgaNB2dC0edrAHCDJuJ2QBdzD/sTF4ij6H11lx4n7353tdC+DsXSfxS6fOEtq4uRpdvqSVq8OInk/NSrPhwmktgqllia+EklJ61npk3XXtpnc= Received: from CY1PR05CA0004.namprd05.prod.outlook.com (10.166.186.142) by BN3PR0501MB1186.namprd05.prod.outlook.com (10.160.113.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Tue, 13 Sep 2016 19:22:44 +0000 Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::154) by CY1PR05CA0004.outlook.office365.com (2a01:111:e400:c5a4::14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Tue, 13 Sep 2016 19:22:43 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Tue, 13 Sep 2016 19:22:42 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 13 Sep 2016 12:21:57 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8DJLtIZ005412; Tue, 13 Sep 2016 12:21:55 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 45C6F1144E; Tue, 13 Sep 2016 12:21:55 -0700 (PDT) To: Damien Miller CC: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: References: <41049.1473653352@eng-mail01.juniper.net> Comments: In-reply-to: Damien Miller message dated "Wed, 14 Sep 2016 03:47:20 +1000." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(5660300001)(626004)(7126002)(76506005)(92566002)(69596002)(50986999)(68736007)(5003940100001)(106466001)(7696004)(97736004)(76176999)(230783001)(8676002)(50226002)(8936002)(105596002)(117636001)(53416004)(81166006)(110136003)(81156014)(47776003)(2906002)(4326007)(305945005)(87936001)(2810700001)(2950100001)(356003)(50466002)(86362001)(48376002)(77096005)(189998001)(586003)(11100500001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0501MB1186;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD039;1:tVGU+buO9b0OApGPo3c5son33REa/9/JKqe3VEplDLs2fwddkEsI29QIwmKF9lnb6s7eJHRLheBhw/VP9ghy+k+221Cx22KgM3BhG949fFvMtgIoK1IxPpR8tV+nqn0infcUzojxDLkp1uMdqg4UQEEhCG9/g6US1JWMYjR+OjHWijdE4rxhuJ9z7Te6RiP8dfrIXWeivQ7NMqsaz4WXod1CtOdiLCUXNq0Dgs7i572A+NpCav31IV7JW4+9h2MB5VtC6zC9NpCF5mV7SdQd07OqsGcasZR2y6ktpaqRk6fEPY74SbUhk1YJls/wcF/iDmd0fNm1L3Lfjj4uC4Z1FxitJAYqkxq4NQGnF0UnktvV0vL647aqGIaxdg4Z8prhP981jlACYqQqzvMHDU3UC6epzJqNGPoqOW/6Xlcu1YHLSam4+94ZUkwDGO/tcVGeEuhIRTRB2XTOzOiEZomMMcHbMA9/zsfWl9deLXDb0/R/xaAptmjmLITuZ+P9hUR8QuhoQPgISDrv2TD012LHDYmb3qq+hbaXdlb6BwlJS7eatsAX0STOeHCGUJAAqDkS X-MS-Office365-Filtering-Correlation-Id: 1ec459ca-b952-42e0-3eda-08d3dc0b555d X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1186;2:17O2J50syYQ5JfL8IzabnZoPT5J2ZX62cNUInOT/Y8CA708YWAJRNY75N8TkGx1gHxHGZzKnSKMU/tpmskG4KRABgLpfku984YESJHYhBzdou+Lwn5ifOwf022blH+O9WE84rbmls8db1KeN+Z1dnoyENh0fdR3HLSqCmOAcB4aLryTLRaUlX6KcvkOtjsVW;3:LOSZLrDLNqYxdWHrihi+rcap6cqj0oxIZO35GG1swjApcn+tALu0+M9NLVfW2VhFYaaqkXlCocZSBKYDSh10vc/qd5Y1WNXu7wX0r1nReVlQcMuyO8B+wNfbCe4YeVizUbAIPPsVilYxuniUmTbN8IorufV3l8fE4NL2KUmO+quCYTlPUA2dnkwliMUY+caZMEDPlDzQgfkHC/Ue4+hRykKPMC5XWEowCcwFNtUt5ZU=;25:OUEQOpsmWTc2Foy1DefkFmD6IS4rT7ToVRtDAUIVB6nD8Q9IhCOO4MV1VjP28ouRZ2+e0Py+qW+WlP7Qe3AfgyFNaJFhgy/IB48AGJ/rtbUliBKWm/RhLcd6nlakz0FlN8LZkPeRaZ2vKB9tkAtPP+/HcuPFc/bSxzx59E8gJt7A6OEPXAV+Y+ksE1KtS7YIv1dXep+VdVlZbtdBOVvK1CPmONj3rOQDMIRdKnLHv9+FoCtcbuKkm6rZTJc3VaVhYea/s82M32+Ci18/b/Ac1vktUBiI1hnfky6urPZirWZMQ7d7sHEFGr3kTKQYkSEh91y7JP37FW3IROxjHYkmK6/BGu+2ANJv8GwyrqQw7j3jT11Rcy+EoiSHq63FVUMlV0PLa/mUwiUBRlGXLDpAtHWYuUOxWVPPgICEjTNTq18= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1186; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1186;31:suMrBHhgM+Qt6rw3JOu/UjqnPD8VY6n+vRKCciwiLfrVsFmOEIBL9N9O2dnE8IraqidMjo//+Tr3ZFzxFk0teiZGEDnMLgBsGJFcrLrmPhItWM/XA1llsgt2VpOHiiqDcIrT3Vl6tGQf0Ds+cTiwF/xYeDEVlA89WYj80qnk7MnEZdmhAfjy3QfX47OdZuCS1/5xcYY4pdkl87HzBGBYqrqRbNyCQ43rHRuHSLQYSD0=;20:6CpvnAs91Vq3qey/sz0thwtafjCW69BwXfVj71J5TCPqIxVf1BybFkIrlDGqkpPYfOiEw2vuzRMXt0HNNzOE2V7sZFVmltpLU+jnAqKlsiHmptlLM8pG/OH6XpWlvNOobFjL6Y01iueTuVOHWL4stFut+2mcwPtD5g9nu2EFPROoGZR3Otoxot3Ys3X3q+P49TbEDj9X1viX6bTA0eIFe+ohTfoXf8+sDoN9c4tsUERNHxTYV4YtO4xTMRO7tYG25Ptk4Gf7cIOToRXiIkytCJohOMUXk9rU6D0spaw4qyjSrLau04qksyxkboAedG1VRxmYhTFSOrsqMG51A9YH/TfREjuDiFCYLkdPy/xI0ZI6W9N4xHR6zqWVs85pvlknB8ujIi936Czl/aPwJAiaUyh7fl12kPelJE/K82bZt4kb1CvOCA5wzxlmn/lghrc9SVcIgUA5mbx3si11WbozSanVCCneDLtr4HRi7wOHiG8DHReeistAsInxsoQd96zd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13015025)(13017025)(13024025)(13018025)(13023025)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:BN3PR0501MB1186;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1186; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1186;4:8XwhmNSHXr+g9iCl9GrfGu3eKrhnqfSip2HWjRMPVEfD481wTnHguK8pWdtx4Ro8eqLNB6W2GfMfTdRqKay7177KL4oQJkDLTA6dOPh4ZRiYVfPSgN5AA/u2xXwqjBDvz+YzYZCVXojHqXBtfXI1ZxhKNHK5SaIPyCSnJ2rVI3vRP5SZSHXqZ3FK6zMtaf1tLOAYCN+yub9ws+CGgDnmOFlQv22/mldsSNcCm9jlNDo4DkVfvN4zc7Du4aUJ5oDovozKxtjOK9Suq2NS0X1yFDYrjwKSR1PkCWZ6IMMggpbT+zSZrvgBZ0Tqiy/E7qEZ7qtGEyk+5XzU+EAB284v8bIjce/w5ZNXFOaNrQwwMkGiwyoU+Z376+yuE94mLXfM7S9O8rkqrjDOpn5ML3Zk1QQw7XsEWbscJAJsuqN+YGSh4nJ7lv7XIE933h7ZhFfeDmeGatb3LqQx1BVdryAOSuNC2bB9fxcVdW+RQZdp46QuDst4+Pn/FBUItplXPs53 X-Forefront-PRVS: 0064B3273C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN3PR0501MB1186;23:Fgn8tWoU93tHtK4LdP58RiKlaRfpG0Xcdac10kl?= =?us-ascii?Q?rBY4YNIOVloBrTJ+g551HrEjLOzeAhGGMkWsAJ83P398JnPi9tUmMec+xLv7?= =?us-ascii?Q?5t+y2KAXPQLk4blSCBS8jkoXLPKKaMxlZvM+h2cZa3jcQMnnorJh1qgjTkaR?= =?us-ascii?Q?aQt5jPdtU8B3xkv4m+NgTNzSlgXKG20OJILoRRtzJCSZFVj+qdpgk2V21pw5?= =?us-ascii?Q?KoM15UURJMPqsKNjrNsnQb6isyd0RvKCrnPfcmmPjHhhiSocpTgFIzUE76zO?= =?us-ascii?Q?WYBkPMS+QiIOXnvucyRnfBTccMarSQ4ORdm9ErcN6Tnc0d9E3F9JatvxUVs9?= =?us-ascii?Q?yaCyvpEll+cBvSW9yIbV3vbr0EbGUuHiMmEephQ0UkOp4sjpMOKnrJF3ngac?= =?us-ascii?Q?FZPF/Imzfzz54AVBlS6CdW4FjTtEBVaGRpNuCu7LfKuGWMt0qa85otShdVrt?= =?us-ascii?Q?xTqt5L0Fr6yLGlYfORsR7YBC0PAUchaZQ4SIQVAcsu5Oq/OvsIrLqEVfeunp?= =?us-ascii?Q?F5s2uexSm60qFNh1XVr06eke7y+mdAwjwzcOhURFpeAMb8cPhhiml7+RCvGZ?= =?us-ascii?Q?sIc1bhsQx5QdXzBg9uptbu+i3zZN9bCNv8/1KKPhzQ/UY4VkdaWasHOP74G3?= =?us-ascii?Q?tEyYl3Y9wiMV6fJgLmLJf46slRAdGaUj7RfB8K3e19O+GIWRDnb3KY4yA7fI?= =?us-ascii?Q?KhLZKdCGQFqO7mVPHJj3pikuxnRVLMsrTTy8Uoq82d7CgZ6fKo5/keiyDyOJ?= =?us-ascii?Q?eSPkZFZg09SpxGIMGTcRxgSm8EVPYlCYNH5eSuAFxcW5Enemf7U0xI1TIaFe?= =?us-ascii?Q?YMdIhfw+1yZ7uxnGRlR3aGSjJY9J+Shuh3g3uiSCkiRazHSEfcItknqw57cq?= =?us-ascii?Q?hso+Mk9sz2YfAOeWE7/oxkIEt5bk5YXeWLE/4XvD3VtcYxLCy4bRBqLU55ZD?= =?us-ascii?Q?aE34MsX84kWmrSr9lfkIOa45FIYCLOPOWe4h8sl2Po1IYMdy4XtKrk24d7zc?= =?us-ascii?Q?rB3YVfocheo9q4yR7jgrQkbJndxtE1bSFOlGcOqm9MqfZesc4Kxjxk7klln3?= =?us-ascii?Q?Je9noa4sIYI/u8K4EtEdiS8OefB6q?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0501MB1186;6:0ONJjJjcYIHTvlwyenZUjcr1OOJ3aQMzHX57UbgEgbEqJncNSq7NXiYofztV3ggdAlTh935GV65+fhDGxvYkcju4pqk1zILsfBxZIFVbjNqYk8C6zA8P+QStR9SOyGD5Gj6GhYzLAiAQEQJ6vaBbcXl6oJju0Iamxf3WQAEF3FQq6YwDAr4AvCeutsh+Se/X9aDSXwGjKM25WZ7aHyMZ/iJ87dJp+vVkMulh45CEQgzQQlq4oKvt5ix+JOt5hJxyZe86zTEIIByqwTgGgATkrpLG4zP2ppoqREYPFu4qGLEQ7ADSeIANjuJncthryH4yj1xzMt1Sv8ek7suS2AkVnw==;5:7nWqIYwNQ0UaZ7EFCIel9Ihb4WPYAbbJ7skBlUGCsJZSQiDTSg5hb+RYyIg+Zrqr/laB0QeycuvcO2G803B2d0cKMMVA6wY4CCFQq3r/awFR68YOueX2VAitoEAKCF5H89A2m45X6EjjVBIl8KpgKQ==;24:EZxCZ5PEnN+X863h1J6phJr+b9v2DJPX4kCD5G690oJLczO+VjiXAfj7Ay0Fi0iRxWQVUz/29H5zMz4nkjOsrlVA+0C06hbS92igXX3PRiE=;7:h7W2bgs6G4ppVXoPl/0mEwJGH6ys7QF3/zJl15G/Ym9lYhY0Bjpo4FhvEzftD7C1SNx9zJKwxk1fyiwg1oZ6s/LWxqf+kENByh6Ib5EvrTzslkyXbi2Ftxve7qOGKRyVUZhMLFFyDfTBKB7qaTXDmLkg0cg6Ti4+iBSFB7jh5FkLTvmKjrUj/4+J1KSKixTgZ9Y0KyJZBnhQOR1f2szfypqT6yIV2S9Eyc8EovMqaPDS3asdJr/ibkF+v7uZt7TX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 19:22:42.0553 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1186 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Damien writes: > Has anyone ever implemented this? AFAIK the motivation for this was > MQV being included in NSA Suite B at the time, but it was subsequently > dropped. IMO if nobody is using it then it should be recommended > against. I.e. SHOULD NOT Hmmm... ecmqv-sha2 is mentioned in defined in RFC 5656 and mentioned in RFC 6187. I see a JIRA request to add it to MINA SSHD, but I am unaware of any implementations of it. I have no problems moving ecmqv-sha2 to SHOULD NOT if no one has implemented it. However, I guess I should ask that of the ietf-ssh list first. > > gss-group14-sha1-* RFC4462 SHOULD > > gss-group14-sha256-* new-modp SHOULD > > IMO these two should be MAY. Most implementations don't support > GSSAPI key exchange at all. Perhaps I need a paragraph like this one: If GSS-API methods are available, then the RFC4462 REQUIRED gss-group14-sha1-* method SHOULD be retained for compatibility with older Secure Shell implementations and the gss-groups14-sha256-* method SHOULD be added as for "sha1". -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 12:32:31 2016 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 2226612B037 for ; Tue, 13 Sep 2016 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 QcLvipY46_MY for ; Tue, 13 Sep 2016 12:32:28 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 B008312B01C for ; Tue, 13 Sep 2016 12:32:28 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4F09385EB3; Tue, 13 Sep 2016 19:32:27 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E556585EAB for ; Tue, 13 Sep 2016 19:32:25 +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 sMWFbSOS-xYS for ; Tue, 13 Sep 2016 19:32:25 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 1EEE585E40 for ; Tue, 13 Sep 2016 19:32:24 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8DJWHHZ048309; Wed, 14 Sep 2016 05:32:17 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8DJWHhs024587 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Sep 2016 05:32:17 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u8DJWHOo009522 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Wed, 14 Sep 2016 05:32:17 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 11389A4F2E; Wed, 14 Sep 2016 05:32:17 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 0C9A1A4F07; Wed, 14 Sep 2016 05:32:17 +1000 (AEST) Date: Wed, 14 Sep 2016 05:32:17 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <38090.1473794513@eng-mail01.juniper.net> Message-ID: References: <41049.1473653352@eng-mail01.juniper.net> <38090.1473794513@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1473795137 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Tue, 13 Sep 2016, Mark D. Baushke wrote: > > IMO these two should be MAY. Most implementations don't support > > GSSAPI key exchange at all. > > Perhaps I need a paragraph like this one: > > If GSS-API methods are available, then the RFC4462 REQUIRED > gss-group14-sha1-* method SHOULD be retained for compatibility > with older Secure Shell implementations and the > gss-groups14-sha256-* method SHOULD be added as for "sha1". Sounds good, and maybe with an asterisk or footnote marker next to the SHOULD in the main list. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 13:05:38 2016 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 B187C12B044 for ; Tue, 13 Sep 2016 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 zBtUMCXF2_fc for ; Tue, 13 Sep 2016 13:05:37 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 715E2126FDC for ; Tue, 13 Sep 2016 13:05:37 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id C159285EB3; Tue, 13 Sep 2016 20:05:35 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 7BE2485E60 for ; Tue, 13 Sep 2016 20:05:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 h3PxLAMkqSsU for ; Tue, 13 Sep 2016 20:05:29 +0000 (UTC) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1E27C84CED for ; Tue, 13 Sep 2016 20:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V70TdCkK6JZAbD/o29pNvziVJmEUN7ZJrCg3ovUXtD0=; b=Y/cH79EY4eQR11TveavuzYqGRiLvcFIIYEI0ZmvEIS9JdROo1W1EBH2BzDtW/oeQUZvR1cGFz3jBW9gPGKTsV4P/eYcEaQmJyJAcVCV+Wrj4JLYFbxjS9ZHjc6e6wMYHhWn+dULcs2vMyx1oeXJ4BSDEpL60t0MVBxdN3TC3yHg= Received: from CY1PR05CA0013.namprd05.prod.outlook.com (10.166.186.151) by DM2PR0501MB1199.namprd05.prod.outlook.com (10.160.245.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.6; Tue, 13 Sep 2016 15:34:48 +0000 Received: from BL2FFO11OLC013.protection.gbl (2a01:111:f400:7c09::109) by CY1PR05CA0013.outlook.office365.com (2a01:111:e400:c5a4::23) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.6 via Frontend Transport; Tue, 13 Sep 2016 15:34:48 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC013.mail.protection.outlook.com (10.173.160.161) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.6 via Frontend Transport; Tue, 13 Sep 2016 15:34:47 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 13 Sep 2016 08:32:36 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8DFWZWD023551; Tue, 13 Sep 2016 08:32:35 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 8B15D1144E; Tue, 13 Sep 2016 08:32:34 -0700 (PDT) To: Tero Kivinen CC: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <22487.55966.466134.811445@fireball.acr.fi> References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> <54981.1473704788@eng-mail01.juniper.net> <22487.55966.466134.811445@fireball.acr.fi> Comments: In-reply-to: Tero Kivinen message dated "Tue, 13 Sep 2016 13:53:18 +0300." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(47776003)(2906002)(19580405001)(305945005)(50226002)(189998001)(5660300001)(53416004)(19580395003)(4326007)(5003940100001)(2950100001)(92566002)(93886004)(11100500001)(81166006)(626004)(97736004)(230783001)(76506005)(87936001)(117636001)(48376002)(15975445007)(68736007)(7696004)(7126002)(86362001)(586003)(50986999)(77096005)(76176999)(106466001)(2810700001)(105596002)(8936002)(69596002)(8676002)(50466002)(110136003)(81156014)(356003)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0501MB1199;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11OLC013;1:JcjPPhdJJW1ZucOEz50v3wKMlu2D7ioK/5NJgRpYVUEUO/20Wq/qPCF+zRj0jLSwrnPqg5VzzHOrkz3HrfHwmoNgECwOTn/IqL4EKttwQmBMO2PdN0S2ZdIMoCrRcPeZSJOx2F3S17gu22nkrI6JGL/awkQDC0mFXMmueM4cekhAGeBxG4zSfwqaRNruYGYq8IHSIFVcIqTqasI6BjB97HHxed2Li+UKvPkj2+4v0q9AqkJlj7UIYmpZfOKziNDJQZ/RferPAIl/iUsKLpZkzTK67v+LSgAzdWHTimki110m8F89gC3GDxM4VzEWvLxDImWHboBE5NQZL1LEN4rNIJXM6t8kgaTzamR7pozPi4Uzkk6NQ03XeOtVRE74aasbhPhaO7uqLtAZ+4BFgFCssVKLRfRisvc0+smqK1Hqc0PvzF9AF6eA7w5ZFBIGVI0nUMGa/jfalC63LUuQ00FO1ee+XoykCP/QybLGFILG3qq0XnmF1uu76Rs2ol4rkDppA+AJSYEPau0TcjqUK3G8sBHzyTruRm7aUUhv0yvCSK/tM69evjZ0kGxHimlxwg+V X-MS-Office365-Filtering-Correlation-Id: 58245304-c99c-4628-f88e-08d3dbeb7ef5 X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;2:0otQucaeYg6+BdiJaNIQlfvW63fuxYW5Ad3iuNCoAB5pFYj0hmHhwmhmwZM9Vw4W8H/wygvxjzhKUnW8EWAOPU4sXgQiuR6O6q8K/jRzxQdLWgWSjxlQSUk3yyTa7abyY6wZ+tVOpzOFyEKovIUS8pOD5TMdvZoBRowdACylRqvKyVlYx3R8j58f1XmpC7XD;3:O6huQtfwxrzB2SbRtLYoNirRrrEzOiZ40lq2FY9mdQqbrGXW+MtjK7AUzU8lRS2mk0hx+6SBq0Aq4tQsmT95J9h4yZrR8DGkBf1an1Xk7hhGwYdLtr+FmAUDhv8l/iCpGZxJsaQb4fEQwbba0NF+VDjZsP5xwnDsuVKrjD2YJ7Sjvmyj3J6JEtLeTqGXsne0BdUzUWHZ+nBeAw2QovvfXJVHegndH2PDER44psOy5ZY=;25:lnDtPMQjCyVqhIV5wZ/7i7IpORHoOqzDw+Fqu/hzbmqphq0J8UdYO68lovSamOflCzm+qGlyKaxQOPj++47QX4UQDCq2Dca0IuygrKMTzMtDl8Jkkru40IVc3/Vv3KsCjF3Od2QSNZ66Ar7sigSTSLyhU0R1jWYLFyS1QuedOMb2zEGWe28UG5fmB0DFuRZRn6tvch+3EtlnyyQreqyitFzZpxiSok/W0rbrscNNiBrLhHvDnGig+Zh3mfzrghoQad9bU/+3RfkvU9SLXQIvJ9y/FtcSMvvCRVQUxZn7JgMy0lzkgVbq5UHQm7S68KMuP70PqRnlBC3tqBPQoc5Rqy7a7egJf9F9Z1wzQc+BfmtOXO+VLJfq7AEkUNbsPYL8+qqu9fU4kR9BI7S9/CGhAfolKskfdIA/Aa/j4VbuvP0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1199; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;31:6T9r+qdiD82tCToiX312/QiWcPnjM4XV8DHtQ8H+/VPRhI3OgvaMzT9WJvWsye2nrvnzDl6gU0bhfGibfF+A6tISwXp1RfZAjBJsJncvTXCwc8nNMj1usCDzJ9xbG9hZhh4Rs+l/BmIc1a4nxGYK+Va2nffaCPVCb0sffsx9C9Oo4u31Jnk6NHmAMjTJ9sIJN3C6PLWiedPtDCIonxgzXrYI0XY0X2gbr02oQ2Km1Zo=;20:xpXp3zpboojKxQZqFawMRzlcEpcym4yToE5fwf4XHBNMvqgRWzFco9X7A97g2h3PhDsAkhwUjsMTQNAa0ZouUL174/wsRsHvM4Y7UZ0edQRuLOxIJHR+9WSSszX7bqtNhZn89wroR29qIOEOJRsfmXxvfxpkku1um9KB82AgDKBR6x8g/RVA27w8k6CTZpwZN+GoMwco0iBenuCkjZ9+Uqj4p5nW0dfkCcYloEEtMMH+WdMLiQgzl/slvXac4lvvcwFjvPwyj3PJSbcEZHH0KKtwewYPxSku3ZJdXhUv88KV7KzjLhulS7TLXbrvHGFaV3kjmOI2DIs6IdSHPF2Ry3OQ+l/XtlnM1ybnWVT7LPa5f1WFBSUyr9DZpjxciDiMuLfcadg/GNYAXYCrZYPaVYaoH3FW+MrpYFwTGUW0KGrtl4eNKz96nmOiAfjuI0aWyxuOL9ySNZLnMSWWpANzQ0i13+nMVF49q9MUX0PzD4mI8R21Ok/ABLsvBBEa/Qpk X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13015025)(13017025)(13023025)(13024025)(13018025)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:DM2PR0501MB1199;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1199; X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;4:2hDhN7iuI0VfnO/yG9N0TliYfO+RhKrRrCngQYXXFchMTbG1y9uWi/nVcB2nMNzeCyGpRJcFpsu+AI3NS4/Shj1dO1/C50Zvbjy7JsJcIKSb3Cxs4GLEYxkGbmIxrijrGVoHwqTdCsG+zpH2+muIo7qeoCqTTXsAJWe86loamdBmv7ENV+XWxQ1EKNdMP5QjVwFRmY3sV5IZd+kzb/yVhveQeCZ8v1uqrGFbgx42v2nfYSv0BIeOTEpst4Byf9Hw8cTjgKO/T/YEKfQYgSl3VjTbNS1sYi0IltldCv1AeOr7ghSMkJCDM27TW2jmhecjNZY+0wnsaNCruYo1lfAgridLubGmD9iA6HtP54wCMvJ6UyJBTTtKVLkeXbGZ7KyOygXASAu6O13dX8+AAqquRGP3bxB/TxpT2oNxxTS5R7FD9IcEg26jEuU11tN9qN2LrBzOuffMFn+dNqLLtC3Ssrkq3FBfEvH90ikPc/QxGrQpQCibuYZQDVatqGRkYFAI3yM59ScJafpJzEsvrpy/zDIwxUvlYE0CHYzQwb9dfqUeG0ipWlX57I8melrP1wi2P8NMjBb8KQIOLjJNKojFQw== X-Forefront-PRVS: 0064B3273C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM2PR0501MB1199;23:8D71IjoLMY0WTg7gj7lb87AQ7xyeQcTb2HXksLS?= =?us-ascii?Q?eP79G7YVl+9OvW2cc4aGwRunoiINkZBBQcp+dBDKuETIqaVq8/5kXM2KXhDB?= =?us-ascii?Q?KeuVFjc5AGLGgjgs5wB7Kw1o8SLfVkbcC7hmzBZq/6pVJxO6Hx4jUD5CRQ1G?= =?us-ascii?Q?uZon785EG+3pMqmTIvu229PGXahBzLDCi2TssAQDFuS2sH01bonrQwfhWsIp?= =?us-ascii?Q?Uhr1k0dRILcijoU2Y/ujtxk4fLsAkUInqtnCsfDy7isk8BobRP9PQkHBbkGY?= =?us-ascii?Q?Em2HRyqBQSwOvhXJ2ozTZpuiKHwQLqS6rSvROcOMLY2050N6oVn4bHQ7S0ue?= =?us-ascii?Q?mmrTz27IqCYJTBP3Dso8QKuFgnG9kWUsF8/UN5Ai+kTn8n8DLJHEkGN+QwmB?= =?us-ascii?Q?Y+35PjvXmD1m3y+fj4kFYkqZAwqMGkvyD39LmF+fBTqu6EY/PmWfbt0vKNY3?= =?us-ascii?Q?A3cOFpR5C0pZsRQosbfZUkNNJ+R88WCz7UZnCBe7K2VaZ97aEWAfcpoHqSMI?= =?us-ascii?Q?hGr4tAv3N5mpA/UV3f4yECcKzTL/NdaVuDaG0Oa8nMy9UKKtOfFMxBRmrhOU?= =?us-ascii?Q?DAtw3IxPmkkl3EPz/PMBqecGZnIpIm2Vqeb5Hxu5gjf6L2tyt+swYEwQ2l5I?= =?us-ascii?Q?NgqlEXLLx+ZcO0yfvfkXXwYR8zSaBbE6ba6DbPw94Zkou2H5B/lftRV+8nCW?= =?us-ascii?Q?uB0zWvZRidO2+Bgi70at03mpGMefXmN5iVvdFcqYf74XwYvxQXj/hwieyByy?= =?us-ascii?Q?hPABHhyIUHpXBUhE7jhfZ3RkF9hdAjn1QMeTWW1QFHzo8K/MeXlJPAZA6w80?= =?us-ascii?Q?O3OFgDQHkLn3mrSYXWDRIp7zW5wJ5A5AF02W17fVFlMz25zdVgFIf5HoORIB?= =?us-ascii?Q?h5bXs/MOnk7Wxvr1c5FvTVH+v62TfQLA4u/TLlDEo7MfESI6ryAcxRKOXC68?= =?us-ascii?Q?zfvLkN6YYvnHW0YawSGoQWj2YlL+Rha4HXznZDEbhP78V0HRvfB+5SBzpq3a?= =?us-ascii?Q?8ejoic5LEhszFy/pM0cw88SYVdYIJ2u+7xk7pjMSb7T+3oHl8gzLi0vK5V3n?= =?us-ascii?Q?sMZYkFd6Bu4JTojZHEm8CInoXVbe/4rQCsEkVlOvYelM6ofObMtRiVPNJbe5?= =?us-ascii?Q?yopU5FcCMhK5py/saiCN4mwW1/6nqQQAsw6+PqBkBkxlH+PtR1i+VpA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR0501MB1199;6:vHfMs/hNF4PoObFSLmxvIS34mvAal+EHet/JKtQjTnicKLlY5rw0Gxnw5Kz0p7Jym8mN820IRMkdaLlpnZ6Z7N58q1hwjF7nI0vWwE+RCMiOFwEEhDcwUI5EC33FzVfjXj/NzWuYlKwsZ9aA9VQY3qP7a1r5REXxOK9rNsA0rNWHxgFCy8c8Bq5OenUX20Y8j1gMOqASlqdNfclh+bLbV7CDCf25Hr0xgt3b4TAT/SdilXHbofS0Xt3Gs3F/W8DrVLrbYqfTmVmr5eUkvTEcwP/WseGQSMw1cXH9h5odslhiykcY/Ec3Iu+M4XddiRvV+NcRxGjDMFbfx5M5NZpdJw==;5:OOnE97IU4e2AtYO2023AaihxbeqHTWhy7hjsryjP48spIqLV/YoLUHnHTlVR0HluOd4nfehXbSSyqXiTk637VOW+TNlK00FzgWThhj1MvZWZIs12aQyyRP30tL6p9XSJ13UcKp4CApvmOlOyfCk3HQ==;24:Q0LZ+eqZ7tCFgGdBxiMvlFeG/2PFD/w6LnoaKko21G+eqco1mnlzJOFPCvyZCxE5rceYCRa/CAkOHGh0NdespniWLsFiCSbR/uoMSqtjCj4=;7:ATH0KyRkCQ9vCM0pRldH3z6zMV7H/iAzABSwak3rfBl5ktspY2Bxvkbn8OlQnU/769rvxAR32gJl9skb/IoF4cv/R41G8NcORV6yrqk8y3BokWCkC4PQtVZpZ/9GbTR4Mr94Nq/ey2m+sILqGadEy0jpXSjr2QlaWwtre0U/eRMe9UKdM6lQr7wxnVYiebLoDXgPstfdmd+cvi5J/uFgRxMMDtVkhq/5rNen1TROOX6iGoMl/9cF88EwQZWFJn+c SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 15:34:47.9630 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1199 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Tero Kivinen writes: > Mark D. Baushke writes: > > > Also, is there need to update other algorithms, i.e. encryption > > > algorithms, MAC algorithms, Public key names, comperssion algorithms > > > etc? Are the implementation requirements for them up to date (I do not > > > know, as I have no idea which of them are now mandatory to implement, > > > and which are not). > > > > Good question. I am not sure if they are all being managed by the Curdle > > Group or not.... > > Curdle charter says: > > CURDLE - CURves, Deprecating and a Little more Encryption > ...elided... > so it seems to fit well to curdle charter, if we deprecate and collect > mandatory to implement ciphers to one document. I agree. > > I am not sure that they all belong in one document or not. It seems > > like it might be better for each section to have its own document > > specifying the MUST/SHOULD/MAY/SHOULD NOT advise... > > I would suggest we collect all "Algorithm Implementation Requirements > and Usage Guidance for ssh" in one document here too. Are we going to adopt all of the SSH changes at one IETF? Right now, I am the author of two related drafts: draft-ietf-curdle-ssh-kex-sha2 draft-ietf-curdle-ssh-modp-dh-sha2 they deal with updates to Key Exchange Algorithm Methods. Of the current CURDLE documents https://datatracker.ietf.org/wg/curdle/documents/ the only SSH drafts are: draft-ietf-curdle-rsa-sha2-02 draft-ietf-curdle-ssh-ed25519-00 draft-ietf-curdle-ssh-ext-info-01 draft-ietf-curdle-ssh-kex-sha2 draft-ietf-curdle-ssh-modp-dh-sha2 and the rest are: draft-ietf-curdle-cms-chacha20-poly1305-01 draft-ietf-curdle-cms-ecdh-new-curves-01 draft-ietf-curdle-cms-eddsa-signatures-00 draft-ietf-curdle-dnskey-eddsa-00 draft-ietf-curdle-pkix-01 I just realized that the draft-ietf-curdle-ssh-curves-00 draft has expired on September 9, 2016 and not been resubmitted, so there is no ed25519-sha256 or curve448-sha512 KEX currently in an active draft. To the best of my understanding, no draft to add chacha20-poly1305 to SSH similar to what has been added to OpenSSH has been written. To the best of my understanding, no draft to fix the AEAD_AES_128_GCM and AEAD_AES_256_GCM to negotiate in a way similar to OpenSSH have been written. Given the current drafts, they appear to impact only: Key Exchange Method Names: http://www.iana.org/assignments/ssh-parameters/ ssh-parameters.xhtml#ssh-parameters-16 Public Key Algorithm Names: http://www.iana.org/assignments/ssh-parameters/ ssh-parameters.xhtml#ssh-parameters-19 Are there any other documents I have missed? > In draft-ietf-ipsecme-rfc4307bis-12 for IKEv2 we even specified the > mandatory to implement authentication methods, and recommended key > lengths (see section 4.1.1). We also provide little bit of background > reasoning for the MUST/SHOULD/MUST NOT/SHOULD NOT algorithms. Okay. -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 22:26:31 2016 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 949F312B1D9 for ; Tue, 13 Sep 2016 22:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 1Y5Nl5jzLDID for ; Tue, 13 Sep 2016 22:26:29 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 94C5912B1A3 for ; Tue, 13 Sep 2016 22:26:29 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 5A46D85E11; Wed, 14 Sep 2016 05:26:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 142C084D04; Wed, 14 Sep 2016 05:26:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0C54E85E6E for ; Tue, 13 Sep 2016 10:53:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id UDg_UfTCejKB for ; Tue, 13 Sep 2016 10:53:35 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 1C4FA85E60 for ; Tue, 13 Sep 2016 10:53:30 +0000 (UTC) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u8DArJrI016860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Sep 2016 13:53:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u8DArIFN010739; Tue, 13 Sep 2016 13:53:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22487.55966.466134.811445@fireball.acr.fi> Date: Tue, 13 Sep 2016 13:53:18 +0300 From: Tero Kivinen To: "Mark D. Baushke" Cc: Curdle , IETF SSH Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 In-Reply-To: <54981.1473704788@eng-mail01.juniper.net> References: <41049.1473653352@eng-mail01.juniper.net> <22486.43242.802279.610275@fireball.acr.fi> <54981.1473704788@eng-mail01.juniper.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes: > > Also, is there need to update other algorithms, i.e. encryption > > algorithms, MAC algorithms, Public key names, comperssion algorithms > > etc? Are the implementation requirements for them up to date (I do not > > know, as I have no idea which of them are now mandatory to implement, > > and which are not). > > Good question. I am not sure if they are all being managed by the Curdle > Group or not.... Curdle charter says: CURDLE - CURves, Deprecating and a Little more Encryption The CURDLE working group is chartered to add a small set of cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms where there is IETF consensus to do so. ... ... The protocols the WG intends to work on are Secure Shell (SSH), ... ... The CURDLE working group will be handling changes to protocols and registries some of which include what are now considered outdated algorithm options, and may propose deprecation of such algorithms. ... ... so it seems to fit well to curdle charter, if we deprecate and collect mandatory to implement ciphers to one document. > I am not sure that they all belong in one document or not. It seems > like it might be better for each section to have its own document > specifying the MUST/SHOULD/MAY/SHOULD NOT advise... In IPsecME we did collect all IKEv2 related requirements to one document, and all ESP/AH related requirements to another document. The reason we have two documents is, because the requirements are different. In IKEv2 it is ok to specify ENCR_AES_CBC as MUST, as it is low speed link and performance is not primary goal. In ESP we also make ENCR_AES_GCM_16 as MUST as it is needed for high performance gateways. I would suggest we collect all "Algorithm Implementation Requirements and Usage Guidance for ssh" in one document here too. In draft-ietf-ipsecme-rfc4307bis-12 for IKEv2 we even specified the mandatory to implement authentication methods, and recommended key lengths (see section 4.1.1). We also provide little bit of background reasoning for the MUST/SHOULD/MUST NOT/SHOULD NOT algorithms. -- kivinen@iki.fi From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Sep 13 22:27:18 2016 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 1D93812B1D9 for ; Tue, 13 Sep 2016 22:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 DLBRBzOV2JPz for ; Tue, 13 Sep 2016 22:27:16 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 8AC4412B1A3 for ; Tue, 13 Sep 2016 22:27:16 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 4C76285E99; Wed, 14 Sep 2016 05:27:11 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id F091684D04; Wed, 14 Sep 2016 05:27:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A4B5F85E11 for ; Wed, 14 Sep 2016 02:20:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id DokjUC226Tqj for ; Wed, 14 Sep 2016 02:20:04 +0000 (UTC) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id D698D84D04 for ; Wed, 14 Sep 2016 02:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=tTzv29gzExYQE9PaK6j/T1KWARWEVWC/S7FMs8IVE44=; b=MUP/L797a7iFLDJtw264rtEZM2DHweLP32Fik25EDtCNeBLBp09eKYaNgiv5Lv6WhAlHr47mcO45s B81xchQPS7/kGrACH89locbyTJEX7tcqSMS6OSgK4JhqZETiRjuFcesXE1udNe5iNVwYwiNLXi50Md KSUZgeRMiv20XHZ1wlDw2COTn1RvFHGBiIUQXJ3RaDQEr10kWGYZYO5C64vruCd7u5WrmaZsAcAx4y /s9nggM5SaSAvjPZ36OAHhERAQZVcOgqtwmB8to6LOGbTFk2LWwBkHYz6lmgk3Gdy28eee4F8ROP7f HJ0517O0ipchcbIcZbNp4lJFybyKIOw== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 14 Sep 2016 03:19:50 +0100 Message-ID: <22FEB0196536431E86029DD43534D1B3@Khan> From: "denis bider \(Bitvise\)" To: "Damien Miller" , "Mark D. Baushke" Cc: "Curdle" , "IETF SSH" , "Max Horn" References: <41049.1473653352@eng-mail01.juniper.net> <38090.1473794513@eng-mail01.juniper.net> In-Reply-To: <38090.1473794513@eng-mail01.juniper.net> Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2 Date: Tue, 13 Sep 2016 20:18:49 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E9_01D20DFC.0A0E6180" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01E9_01D20DFC.0A0E6180 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable According to this page (great work by Max Horn): http://ssh-comparison.quendi.de/comparison/kex.html ecmqv-sha2 is listed with zero known implementations. Note that this might be inaccurate =E2=80=93 ext-info-s is also listed = as having no implementations, whereas it has at least ours (Bitvise SSH = Server 7.xx). But this is a new development (first released a few months = ago), whereas RFC 5656 dates back to 2009. It might be safe to say that = any implementations of ecmqv-sha2 are indeed very secretive. denis From: Mark D. Baushke=20 Sent: Tuesday, September 13, 2016 13:21 To: Damien Miller=20 Cc: Curdle ; IETF SSH=20 Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & = draft-ietf-curdle-ssh-kex-sha2 Damien writes: > Has anyone ever implemented this? AFAIK the motivation for this was > MQV being included in NSA Suite B at the time, but it was subsequently > dropped. IMO if nobody is using it then it should be recommended > against. I.e. SHOULD NOT Hmmm... ecmqv-sha2 is mentioned in defined in RFC 5656 and mentioned in RFC 6187. I see a JIRA request to add it to MINA SSHD, but I am unaware = of any implementations of it.=20 I have no problems moving ecmqv-sha2 to SHOULD NOT if no one has implemented it. However, I guess I should ask that of the ietf-ssh list first. > > gss-group14-sha1-* RFC4462 SHOULD > > gss-group14-sha256-* new-modp SHOULD >=20 > IMO these two should be MAY. Most implementations don't support > GSSAPI key exchange at all. Perhaps I need a paragraph like this one: If GSS-API methods are available, then the RFC4462 REQUIRED gss-group14-sha1-* method SHOULD be retained for compatibility with older Secure Shell implementations and the gss-groups14-sha256-* method SHOULD be added as for "sha1". -- Mark _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_01E9_01D20DFC.0A0E6180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
According to this page (great work by Max Horn):
 
 
ecmqv-sha2 is listed with zero known implementations.
 
Note that this might be inaccurate =E2=80=93 ext-info-s is also = listed as having no=20 implementations, whereas it has at least ours (Bitvise SSH Server 7.xx). = But=20 this is a new development (first released a few months ago), whereas RFC = 5656=20 dates back to 2009. It might be safe to say that any implementations of=20 ecmqv-sha2 are indeed very secretive.
 
denis
 
 
Sent: Tuesday, September 13, 2016 13:21
Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 = &=20 draft-ietf-curdle-ssh-kex-sha2
 
Damien=20 writes:

> Has anyone ever implemented this? AFAIK the = motivation for=20 this was
> MQV being included in NSA Suite B at the time, but it = was=20 subsequently
> dropped. IMO if nobody is using it then it should = be=20 recommended
> against. I.e. SHOULD NOT

Hmmm... ecmqv-sha2 = is=20 mentioned in defined in RFC 5656 and mentioned in
RFC 6187. I see a = JIRA=20 request to add it to MINA SSHD, but I am unaware of
any = implementations of=20 it.

I have no problems moving ecmqv-sha2 to SHOULD NOT if no one = has
implemented it. However, I guess I should ask that of the = ietf-ssh=20 list
first.

> >=20 gss-group14-sha1-*         &= nbsp;         =20 RFC4462       SHOULD
> >=20 gss-group14-sha256-*         = ;        =20 new-modp      SHOULD
>
> IMO these = two=20 should be MAY. Most implementations don't support
> GSSAPI key = exchange at=20 all.

Perhaps I need a paragraph like this=20 one:

     If GSS-API methods are available, = then the=20 RFC4462 REQUIRED
     gss-group14-sha1-* method = SHOULD be=20 retained for compatibility
     with older Secure = Shell=20 implementations and the
     = gss-groups14-sha256-* method=20 SHOULD be added as for "sha1".

--=20 Mark

_______________________________________________
Curdle = mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_01E9_01D20DFC.0A0E6180-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 29 07:47:46 2016 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 95D1B12B0E6 for ; Thu, 29 Sep 2016 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 esZJbOpODQjs for ; Thu, 29 Sep 2016 07:47:42 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 42C2712B308 for ; Thu, 29 Sep 2016 07:47:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8FC1185F17; Thu, 29 Sep 2016 14:47:40 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D6D8385E94 for ; Thu, 29 Sep 2016 14:47:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id U0-E7PzSJqrM for ; Thu, 29 Sep 2016 14:47:36 +0000 (UTC) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::71c]) by mail.netbsd.org (Postfix) with ESMTP id 173C785E5B for ; Thu, 29 Sep 2016 14:47:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xc5mQyA6jCQtOSUcStsQI0NlRyv1h9157czuDdJxl24=; b=TJqVQTlaVvGsr2pNvQnySuC71mDFix4hNfWy7QYOIwRFzZEpm4SMEu+TMDd0KRqK0HEiTq5O0G/xBKEkMUUwwG5CBRSvWV7qgv9dsa1ulLUCkQG2Ww+bvnh//aGt1T/rr+ldD1LEEQuePRwRzgB7SmzMcMjQoFMdji0io++5T9k= Received: from CY1PR05CA0028.namprd05.prod.outlook.com (10.166.186.166) by CY1PR0501MB1337.namprd05.prod.outlook.com (10.160.226.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6; Thu, 29 Sep 2016 14:47:32 +0000 Received: from BN1BFFO11FD050.protection.gbl (2a01:111:f400:7c10::1:194) by CY1PR05CA0028.outlook.office365.com (2a01:111:e400:c5a4::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8 via Frontend Transport; Thu, 29 Sep 2016 14:47:32 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD050.mail.protection.outlook.com (10.58.145.5) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.5 via Frontend Transport; Thu, 29 Sep 2016 14:47:30 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 29 Sep 2016 07:47:28 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8TElSt3030671; Thu, 29 Sep 2016 07:47:28 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id B6EB811446; Thu, 29 Sep 2016 07:47:27 -0700 (PDT) To: , CC: From: "Mark D. Baushke" Subject: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors Date: Thu, 29 Sep 2016 07:47:27 -0700 Message-ID: <35937.1475160447@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(7126002)(117636001)(626004)(2906002)(92566002)(5003940100001)(15975445007)(5660300001)(305945005)(86362001)(8936002)(11100500001)(87936001)(69596002)(68736007)(15395725005)(4326007)(7696004)(586003)(19580405001)(8676002)(229853001)(2810700001)(106466001)(50466002)(48376002)(19580395003)(50986999)(81166006)(54356999)(81156014)(356003)(77096005)(53416004)(97736004)(5001770100001)(189998001)(47776003)(105596002)(76506005)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0501MB1337;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11FD050;1:ADUyyXv0hqC88LlpB1PJUq8TUlPrvZz9jtGtXzR4N0RbgPIU/jVh+3tkyslLWqaQw1BE1nfROgrdO8zGsuUYb111kHAAhZpah+BDtfTsFwh27WzrWKOVE89dlms02fXqoMntZeP3Bz170Uyi0Vk18WfCArMHCddbUXyWxCEY1PbYhxNuNaFO1c+QmydZb9gmiQSliXNAgd26VurCbdgV8Pnqx9j01U9g6yDOYKZ/+bImkeSncc6Pfb+Ynr7alkstpY8dR6PJdoV/MVo8GFmoU5+BhTq2NUC1qRjGJT7vmDNtwZrEVpeVeX50QDmsL//zpC0b09YrA/tN+dMKYgRkoZrWguvcNXlcJj0q6K06muOmbGaGcaIrRQA3mt8krxpv6ASvnXGLjY5N1u91NU8frhEbYOM3+KcjCnQZpuxBQpN7PInKpOhU3lWJ/qe7oYYrNlsRa6+uTCM6J58nEzHUpuFJGN2Z08/SGe/ubKoeV6D6iPG0w6mRQvUST9X0DDehyYH20icuRcCHawHiwPTpoKK4aVpWHEXdEz9c32RkSmtB3Dp8Bx10XYlBsrK6vIlD X-MS-Office365-Filtering-Correlation-Id: c3244b47-8f9c-48fa-6956-08d3e8778abf X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1337;2:OSNR8b+qtTwkoexJp9bmN57Xh/o5F8BfiWcNRk6ojmpodIdMqh8SUN/yhgvwB9Mz6ZTF3vHTUgbL28GWFYuONuYn8bgnsUwDMXqp5hp1WK4D3mA8HjVXSGK8SqLhUV6VZ9l24OO3Su44XFE0NDnpkaXDN105vHBlqLbg1nJ8MxgfDTjutkg3e465eOJodor3ecRbGnj2PMsxbocg6YDJGQ==;3:mJaBOqyZrqxTaYWsI0f8O7NVuvva2FASEj3lf8obuHXcmE/L6I4D3FugxdW8iwnLQ8lCOCYOAIKMJD7nWtSmb2+bNuHUNjaFq76B/RANh+PeBFY8koElnxlsIrWXO88zqkU963i9Bj6ChbSJv7Fm607m1AqctvE4Qyh0C9qFtuI7VdI9YrZCBxgS9YT3vDwe9DNGIlanJhgr5LnIGrxb60hij2Z0Cn+5kdhPWIkvaB/jGLdpGzvVhCPXU5sybjOV;25:bObbQQZWQBnFEIR/xelKpL30cycd+RQKeIc3W8wuuguNHDaEDalH9bY/AvA7G50Gll4EBracxgCNp6h+9abBPigZTSXe5dizPxICX+BG6TjUXmXwx5AnBZbiBq9TYjZJ11ThwQRwRF3m4kyud6vDKHS6IKLuAMJGxa3QMn11Xi2sYzeT228TfLO4vqCYKdRt5fDxvZXy8cR2XtOV1AdsNGA15AiuXpJCJMxSEGyW3flFlUBMmp4GdHIHLm64vRlOhgvZ3zxH9TRWVWbsMAYW5bZSRlXtrPoB6LREx6un+ebXt3sI9DnYPfThWw9oEEVc/SOEoBe6odGSHBapUdDYjngs5kGsvYIVjsra+zyJPX0RhSyjoVtcs41fGh6VvxPCI9eIhrxeDIs9B3CbYCbYm2PDn4AE4y/yROChGx5fP7ofvr1+uA0ifw6FkpfT9Z8u X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1337; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1337;31:xe00oWvJ9J5fda3AQ8iOHSH9dwpN8MOTuByyHt1fQrxV55yZvNuYU9Ql+J1jcEDrxXoqZAHcegqhbWkxdRvTj8v/+Qxfb5GkJkbVeqpZtZe1nc8vMcCznfs57n4XKXRoEXzH1eSB+ArHgSNsg/IX395fxbSrIutF3v/JS3XO9ksKdXaSIEkrqqiRKQVbVPE1wCirLq1O9UNjAziriRhw+mZk2bWEKfvnlXJrV+nqZdaUPGpDRfnUKv5YjOX2geKC;20:YQZ1m+VoX7vY2CuyzKxUdHlKwzwWcUQH6Uqnh9ULroywtnypXenmPQa1Ox+c6oPlOOwSG6i7Zoc+5X3yBKpzs9jDjgWveiBtjqVYEP/6yY7r8vu29NFfmsayq8PPdAdPh4tQHHKzMd4iLEzFHzuNxTFx0Rr+zh8tqwiS6ojJObPSP7/W69lYNmJJbXwxV44QmT5+KQq7Tl55R2opxUhN0PyHyrq9n+xhS2VKzavo6Sta85wrtAs3rmGGFIi+VWpeCP55UqZbteGsg5RkUytvqk8aoSmFcizWHErpsECe3aCG/0qcR9pQryecoa+zG7gsJbohttO/YlDGPQu9y81th0XrTw7VYgpjkNqYKCwNLjx42BO0iMTGC71FG1NxS5pM1XFJmJbBgM+ULp5Fvn9l0h6pRURelHFcNk9Fvw3kleQfMrbVQyTWB1PbN6q/oICUGF8qTiHmeC3MR0jnsdq8T5kdFECdZxKt1y0nZUKOytFgMMLDY/BaYsYnTa2RVIzg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(13023025)(13015025)(13017025)(13024025)(13018025)(8121501046)(3002001)(10201501046)(6055026);SRVR:CY1PR0501MB1337;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1337; X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1337;4:Ukmuk2KcHdEATVWFypJ/AweKoRGE9iMi+WbYo6lACZhjtUcuRqISY93j+iF4bjRj63XJwrkB4dDD+qqwLanjrUXNQmn1VgG62YTEy13Kq842rUjPtRc+wZlAryOLVhl+YOwR69FWxMudGm4svQXRz/+id/cNE6hCs7B6k0HDrwiS9MAStML/s42svknk20LebW5RMf6ypXGtuTwWEiD6pXZna8e3+hkgvIYs6fCqmK2Qqwcruypn2wUCASy/+K9OM1L70r2OsNCaUKpPyl37CVoiUIoosCjLc14Q2GF+cP/ZZHKgEaMXQ38c+RYv+rRpoOAuKjVCtAlVqXP+DdkEfzkElPbvWM9aJolJytZpVSHnzFz8xBIt/80Kl5VlU/5RvOdvPeFhyIKUV1Jlu3Sn2M1nDrUi4cPWqtdqQ9Ko57R8Y9Uw17eEqdnHTDG9s7WydCRAfC+sGSOfV2tQ1kuqmP9/DVcQ9XlxVgCL6l9fnX3RfKSpWLXXINGdFEoFKasTV2cO8WgSklJXASvVOPziy9cLL31lep8ZV9NSN8sG6KpYuNlsgwnpTR3NRt2X3/y/S0XWqpXN9uZViHZavpnTQHCHsZiAFI4hJe882BvWSkVvgyqM1geaMVELrB+xiOK1 X-Forefront-PRVS: 00808B16F3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR0501MB1337;23:LxvIZhktVYHvynTPu842X7kwJg8d4a9nrRBI+BD?= =?us-ascii?Q?0MpBZKIVIeqLDUM8xO96RSMQzTO7F9J7TVNwP6lk4siDOJC+exmg7ANUN6E6?= =?us-ascii?Q?Et9gZjxz7QbV876IwaMjn/4VdVG/pmDGFnNLSwaRD0eAyYkMVhk3IR5CBUe3?= =?us-ascii?Q?si3Pz4lSB/oE4QV3yC8UldV4tLaJaqB4US7AgvrE0SWDDY5TUDHSSTTE9LE8?= =?us-ascii?Q?zl2q+7lO5EvQTaU8x0bz+fJumnv/uFr3FmAE/83rL+tkYOADl2SyGwZTrFd4?= =?us-ascii?Q?xN9OafSPpbDiBCjUcgBRWV1y5Om8fQM5/P8vvE11VkHROsDneZ9MsPDWHH6z?= =?us-ascii?Q?vZRaileLdqOkGB8hJQKjeOQ5aZclaHntiG/PNT2Sd5S/Eic3uaOLNlI1DvEt?= =?us-ascii?Q?Nf7e8kx7iSXbdN5leRGLQhqsEoi4h9Jbm8bDeEWrpHABCzjCkvL2IkmdUMhc?= =?us-ascii?Q?97i4tKC4uELO/V7474xXlsTi8FPgIqzUVQysFjnYH02aCeo9tWUgx3Y82kRZ?= =?us-ascii?Q?wrA4My0l5lECoAOkZD/CHhNz/I9X3TWYTUPnamexQn4X+dt/u/5VTL6eMPq3?= =?us-ascii?Q?l+Z+isI4n3CSY3F+3TA7L+bjUSwhctq3bxsSfmrd+7GIBhAaJpM4EhFzrZXm?= =?us-ascii?Q?o0UD11SEsNY0ssJpYfhA6wXQfG4EVSVCD7q2nv1jnflZWV/fphS52G+AlNlp?= =?us-ascii?Q?Tmv0b4Z4nwIYi22zbAo6nfN7B0OTvh5UddmQP9S5bw+jG2kivBvv8n3uKSK0?= =?us-ascii?Q?yIKogEzVwlK9/NjXAF5n0nVC7Ao3Hvb7+TeXWNpeVhhK30IYdMh3QssYiyud?= =?us-ascii?Q?gIMNnqHccqHW5oJkmWxAsmpBS7h7I19dYj8kHbzh4e/ZNxGLH1b7bWMtf9iT?= =?us-ascii?Q?p7fibom03lCETxWisJXMEUfw+DUwy6uHgPHrzX+0dCTyI3Z8u6czMe1WuqwI?= =?us-ascii?Q?0G82s3zPj2dJftZeGmjbJ8VcAnumcDjSky0EG+/JmD/LZWKgkU9SKq7KNspJ?= =?us-ascii?Q?VEkkn3p7LrEvtY+dn3BZnZJJHRHQ6jyPjOkEjbQxVktql4uADt602xWeA7T8?= =?us-ascii?Q?eQCxxm0c3Ah7hYNU0KvNXgRV5fV5Imqc5YQM9IMnnyOV6VqvMKcDt/3KoJvS?= =?us-ascii?Q?R9hXvIoOvRiP1vI7YvgSVL+HS0f/Slmhq?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1337;6:mFcCvZPXya/09W5XqGksnXirocFbCi1sjAj5fLvscT0FKAUOcuBhOYxB3NhkJPU4i8xADPdYt90fG7l9r0PVKNH0zFe58FdlPAd0wze+Qn+eASM/4P+E2zv+3yWp3SnguR2D+XegIKCMmEoVPuHiyor1B91c+1s6otQT7PlrqsXy41yOkn3Y5DtB0VExSHxpvcrXdadDA2aOgmTyq8papkThOEeZxuh2oKkomNuVgtpJ78Z4c8zr4J9Xny7qwjUdefqmLOm9p38b8kSeoM0T/hkqblYRzQNihQZWs8/Pv/RVggakoqMdN2aUsWzJ/FGDKkUiUJQ7EbmhNZW8RsXFDttbA3u6uquj+J9u12T62Ns=;5:d5WkToaQtmR5ZJrpX4NpX5O8JwzkCSDjDx0PLMOvVXQhltyJlX6rBEJuREoitRit5yvGSImGbhGEito1+uD3xL74p3ayoUb6D/w6mSu5rJQsvycr6LHJua9KTFBgwsI55prmPm9D3jicims1e9Sm3YXjoWDIJtuEfv+cokvffHo=;24:oHlGE+vBUSDfwuPDOY+WgmqA5F+2h/TMKiBLbVkyDL3VA7352Oaoi0DjX7zJhfADxHbqNGsaPADIbsX0n4OcnF1YuyQF1aBSSfjXWWrIY1I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY1PR0501MB1337;7:LmeyA7dDCyJUVdQZZXFWlMc4BtZu4nGwFXGjavmSGf5m7knqEJyrP3SqFtOtL8M3qHdp2aBCYkD0ecWzwUqILUbwz+FceFzNKMWH8BBYr5kwDOPu6T38RHDFOdv7y9ja80FtGxI5tDiu8xmdm0RyPTyd857Wt+iTB0Ly07xtxcZ08YSRLa+75U5I1EMikqUeSBv1gXTmz8tDsWIX0oV0rOSUpHmzRL6wlKPFCl5zuhL3h9WX9TkyLqX0/TnvYAS0Hezsat7qQJWuHXrjKTjy28KZgN6PgPfruUbefkOUIej+WqcUD/WzcB43nOr3hI3D7OHSE/CAcAAeCQAJjC1A6Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2016 14:47:30.4380 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1337 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, Question: Should RFC 4419 - "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol" be deprecated? Background: The paper "How to Backdoor Diffie-Hellman" by David Wong https://eprint.iacr.org/2016/644.pdf describes two ways of creating a Nobody-But-Us (NOBUS) Diffie-Hellman backdoor: * a composite modulus with a hidden subgroup (CMHS) and * a composite modulus with a smooth order To the best of my understanding, the only place that the SSH protocol could be impacted by the attacks suggested in this paper today are in the use of the RFC 4419 "diffie-hellman-group-exchange-sha1" and "diffie-hellman-group-exchange-sha256" key exchanges. The mitigation for this kind of attack would seem to be to use safe primes of the form 2q + 1 with q prime and ensure that the generator g has a q-ordered subgroup (g^q = 1 mod p) (c.f. FIPS 186-4 A.2.2 Assurance of the Validity of the Generator g). The checks for Attacks on Prime Order Subgroups is also discussed in the "Security Issues in the Diffie-Hellman Key Agreement Protocol" by Jean-Francois Raymond and Anton Stiglic of Zero-Knowledge Systems Inc., IEEE Transactions on Information Theory 22-January-2002 (google shows a few URLs for this one including: http://instantlogic.net/publications/DiffieHellman.pdf ) However, with RFC 4419, only p,g are sent over the wire. So, any attempts to prove that the Diffie Hellman pramaeters are non-trivial, or make assumptions that q and p are computationally related. Indeed, if someone is generating a Lim-Lee prime p (which is a very efficient way to generate a composite prime), then q is unrelated to p and would be unavailable to validate the generator g. I am wondering if David Wong's paper is enough to recommend against using the RFC 4419 ephemeral DH parameters entirely? Or, is there some useful way to quickly validate that the server DH parameters are valid from the client? I would appreciate any feedback you may have on this matter. -- Mark D. Baushke mdb@juniper.net From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 29 10:29:13 2016 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 4BF6412B141 for ; Thu, 29 Sep 2016 10:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 nQw_jmhVukt5 for ; Thu, 29 Sep 2016 10:29:11 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 F03DF12B025 for ; Thu, 29 Sep 2016 10:29:10 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 91BD985E96; Thu, 29 Sep 2016 17:29:08 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 1A94E85F04 for ; Thu, 29 Sep 2016 17:29:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id DrsmGttQ52di for ; Thu, 29 Sep 2016 17:29:06 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by mail.netbsd.org (Postfix) with ESMTP id 4A27C85E79 for ; Thu, 29 Sep 2016 17:29:03 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8THSt3E023745; Fri, 30 Sep 2016 03:28:55 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8THStQ8021354 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Sep 2016 03:28:55 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u8THStx1011761 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Fri, 30 Sep 2016 03:28:55 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id E4BCFA4F2E; Fri, 30 Sep 2016 03:28:54 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id DFFFBA4F07; Fri, 30 Sep 2016 03:28:54 +1000 (AEST) Date: Fri, 30 Sep 2016 03:28:54 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: ietf-ssh@NetBSD.org, curdle@ietf.org, frg@irtf.org Subject: Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors In-Reply-To: <35937.1475160447@eng-mail01.juniper.net> Message-ID: References: <35937.1475160447@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1475170136 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 29 Sep 2016, Mark D. Baushke wrote: > Hi, > > Question: > > Should RFC 4419 - "Diffie-Hellman Group Exchange for the Secure Shell > (SSH) Transport Layer Protocol" be deprecated? > > Background: > > The paper "How to Backdoor Diffie-Hellman" by David Wong > https://eprint.iacr.org/2016/644.pdf describes two ways > of creating a Nobody-But-Us (NOBUS) Diffie-Hellman backdoor: NOBUS backdoors aren't the only concern; another motivation was logjam-style precomputation attacks. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 29 12:23:08 2016 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 6D50612B1BD for ; Thu, 29 Sep 2016 12:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 H3MPm0AoYthb for ; Thu, 29 Sep 2016 12:23:07 -0700 (PDT) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 096AF12B19C for ; Thu, 29 Sep 2016 12:23:07 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 2F3FB85F3D; Thu, 29 Sep 2016 19:23:06 +0000 (UTC) Delivered-To: ietf-ssh@NetBSD.org Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 825A185F37 for ; Thu, 29 Sep 2016 19:23:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 OB6sPQTlF7m0 for ; Thu, 29 Sep 2016 19:23:01 +0000 (UTC) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::72a]) by mail.netbsd.org (Postfix) with ESMTP id A876A85F2E for ; Thu, 29 Sep 2016 19:23:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ja41gNhXoNAaWEICmyx9IKz3b8zf26kogqecoUBAmCc=; b=BEkW5+AqKwoNhodZ8lJ6kou3azUapf/J0Csp8CRN/Ooy6U7M/2/sI4pWbOqdO0GPO7qusAPz4NSsnTFidDSlLSIGJ122w4JQcj3tJ1nXg5jWi0k4c5QTQ9LFqxr/gY7r2Dw5Gtn34dbdwqlh2KGQ1kvnLois34NglI5lp5bfdGU= Received: from BY1PR0501CA0042.namprd05.prod.outlook.com (10.162.139.52) by BN3PR05MB2723.namprd05.prod.outlook.com (10.167.2.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Thu, 29 Sep 2016 19:22:58 +0000 Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::155) by BY1PR0501CA0042.outlook.office365.com (2a01:111:e400:4821::52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6 via Frontend Transport; Thu, 29 Sep 2016 19:22:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.629.5 via Frontend Transport; Thu, 29 Sep 2016 19:22:57 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 29 Sep 2016 12:22:56 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u8TJMsr9025343; Thu, 29 Sep 2016 12:22:54 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 32A5311446; Thu, 29 Sep 2016 12:22:54 -0700 (PDT) To: Damien Miller CC: , , Subject: Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors In-Reply-To: References: <35937.1475160447@eng-mail01.juniper.net> Comments: In-reply-to: Damien Miller message dated "Fri, 30 Sep 2016 03:28:54 +1000." From: "Mark D. Baushke" Date: Thu, 29 Sep 2016 12:22:54 -0700 Message-ID: <91352.1475176974@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(24454002)(87936001)(2810700001)(19580395003)(19580405001)(68736007)(106466001)(50986999)(76506005)(54356999)(76176999)(105596002)(53416004)(117636001)(2906002)(8936002)(4326007)(5660300001)(7126002)(626004)(92566002)(81156014)(8676002)(81166006)(305945005)(356003)(47776003)(6916009)(7696004)(110136003)(97736004)(586003)(189998001)(5003940100001)(69596002)(2950100002)(77096005)(15975445007)(11100500001)(86362001)(48376002)(50466002)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR05MB2723;H:p-emfe01a-sac.jnpr.net;FPR:;SPF:SoftFail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11OLC003;1:Pg2vQ3OI5PIDhRZcnhtuqIsPajgnexZmJIZZ0aOoLGKN0ooGEJOl4gqWFmx7Sv3orMXOgGRP4AQsgqdnq7714XYW2+WKkSRhfLF0v9v/zt+b7tfrrdrgTMiuV5kVt1Yw8YAMNCWGMYY2Ui4mg7d9gbNTxyrFAiRjt5OJrnToe3doDviW7GdsYhd7toayLVJpDXowD0ZgaWfWdKO+7CN/b/UkK57QOtmEblZwjU5FwfbzNKG5Btd/8//l6MkiDgZkwx+TZVO35wxl6geC1Tp0nXh4xlu1tPDbz1uwnktCPbQOp9slCJ+CyJx5Lk1k3nKcU3AYb6wiXyZIxRGyKsyQs/MHZD4HiIhBbrGo/psNmqlWPLW0EI+XdMOw+rDfmcz5y6v5nJRDQaJNBfiYZblWcOovO4Fk/soJdLb2Ro78QvRmMjHsuw1epO/QQFaZgAJiN6OAfOjMb07+g3RS3oq++89wvj3+y3qgVQMTMXvPJCYUAcYC3LLqv2FplDjKAgLDcpllKuaFS6hBmfHB4X89DJ/FExrLqDPoSFcJB7245ZWO6P/AxctKusLTrs7v+555 X-MS-Office365-Filtering-Correlation-Id: c1bff9bc-74ba-4669-c69b-08d3e89e0537 X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2723;2:NMNwq4EHhpLAU77QCS6pDjrC2gbqI5RJHs/NLR1knkCy/WLIiuoiaocxxRynbOWk5g/HGS9ivAhdxAVdxhUWinphLeFX4h3DCqj6t7MGhmZR+/WbPUDunpqsomizO3HM8ga0vrUKwuEy9XCe1jppou9/DbIyQ4CoLe4YIqwu4+s9AKwsABJ0lpM+hpkuKKsNNJ5BioIjplqnQ6f3yA8fYQ==;3:pv7DTYTHqOrNLNh3M/f1NI+ble2T/Oz8Dmjv5QFnyAaqmp0MSuut3VCkyEXdkw/yug7ZHLks3H2f9GRkFpXTmTOFYwVLxs741TXJkZS2/IMOUVYfSOLaoXD+Ew8A54hq21GQPDo1Jgz0IpjKnUtsz6FV+pkn5C0xn/PnnOf5ylixLwh1UMvEr4O1IQB71tR7htnA9AH7LCMVX9j/uTpBJm79TAW0sfw/aS/BxeNpn7DsbbxkfZ6oXPEXKcUrDcyD X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2723; X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2723;25:HmyYpQex0ZjSBaUPLJkxeeiFjMrAH2etBxfZt+5tn0/Lwb4g9FbxPzkxXyG8aEQk4Mro3zVBTUDsjheTkE9D+goRplqHgUEIGZyL9TtrEvLvKE9T0A8p61bpAKu6jJMXCD23R3TdWgYsc1J2eRmvuyrnthfzS/O9qZlstAFUqA0/I1h5OdwX3Wf8ABJBNmb2nltslJmMCXe8dDOcQgKceQEKw8yDbC6VKKSWzL7wPc/q++KR/4PBnLAIrKh2hnfwEp/LR6SpoChXP2VJle+STOJOw1U66ioKF00qoPAEOTWna6VnsCkGl4LJ63Fl07OF4WevTrHvfMG+KNSJoifFkYzbkcsUP1duTYFFfQEsHIvtAlnGQTQ5qQTd/SEEG5s27CoxSFUpdql2LS5wA1/IoGrQsKcbUE0+kxwuSTZxSWpyst40gmZx4nAqnopL0ORlCV84fx2NI+82/jNVaov6XMFUx6AamNXdXkXjh6G1YGLN5AVHZvAHGlXi3cxzwqPGfvvsCPP/jExKtmPv1KSHY2+6F2seLtIPzszO7fJjz8irYp0iCIZ86BWszevM3bcJ81tjZoBgrZCvIrNpvMR6K4YZenwGfvliHHgSAQHpcpQB1YWWNWk6EqSmrKgxl33BB/0U2UCi1y+ncD2g3VU9jfLeGoHM09QJaEn4bamdOsTj0onPA+JX+zeZ0rlsXx8NFlfEmtlusPMPKUUWG/OeRyIYNDPOBqedjOZDGB69hCjBsoBnCJUTOMeoJO564cfKFNd/sCpEDlPss5YY4ppIfoBCbUkxED4Zzvb2GXg3b8gsH391L9uF0aTezKZhnV8bfh+DyDY9m86V6GLFI3mgryZ5T88BE8VICcVQdfZznZTh2s9KHXVle7WltWOYAy+d X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2723;31:1efW02NzKsfNQ1EJm+jMnW8fMwR75VBfCXyCC/w/+s9kl7hZNy0v8ApP0hpxq4LHg2Cl/GPJS3+Dtg7fgCEoLU01wqMQuMtNcInf6sPHeIapGfcUUOKWM05oSG1Ux9YlLGgAFNPMNOCfDI8vlzwbTYxBcU9z04BzHBdIOcUqxTSy+SjWCCUJz8tKsiplupRaVM58qcNFRFIC+iAt0LLpsQuH7KRgnzF9Rj5bW6vqcdDi5KGqlJTLHOmIsuGIL9V5;20:TbDwPceDttGbrbU7JRB3swQUQJFM9UzmmJmSssCpo5zbKAu2SKdd07iE68J/h0a+xJcpXtmpAtryKwPuYXfROP15iNJd7GuvmeHZl7+lQH3UeksJRTfivpTduoYcjNgVoVXkuPJI8Lh8NH5c8EVoLqWXLkvUqY6OCfzEp7t8mYQWObKHXNSL1mT6mFf8FR+oOPZJvs+tQCKyAYNErlSpsxQmEx5aY23a0sl5kXkNqeK+XPuFvwWK4yJwfTPjU7ZSg8Y4dmKSp/R1pM5dVMj8HqsAlZwuzdNzOiMvutYb85k05tgkpZwtqxn89X7FaPnkXjGdS+WYT+o63wP+KikJpDG9RWa4FHEnfTssGfwZ2BF91jxmSIQ8sSs5FEXP55UWvZ3THPbEXToa1EJrnyIs9XRYE7e8FhVwSdK+clLX+mlB3eXki/IUJLKautCMpttxhpQWWAovvIu/xOA+yGY8KtjXvsQnBiij+g+Kee+taQzZo7S+U+xXYRt5HEl5E/E0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(13023025)(8121501046)(5005006)(13015025)(13024025)(13018025)(13017025)(10201501046)(3002001)(6055026);SRVR:BN3PR05MB2723;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2723; X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2723;4:Nx/zHw8fStRaUmZPLt40pLpN8PT0+RbvJ8RwvviQRkppzl3F6+V/lwRJDqIPpe04ot+dL+hx4odr2SycfixpDI7BDh9EMn2MBpaEeAuoLuJhbnHV8eTZXUwmGjJmOXS8Z/Y+FE4WhWuTLUJ+5OtAABjLEb+anBc0WO0zlTu4s/I9rv2Bg2hFwCxrayaiGXp1bKPolSKkTBccbHWKWxuYeKphxrXJ9HOcoZCO+PNo/F7DMTmqsgoRf6qz6fM4OGoebeQDXpI1lsmVPPeaAE6kmULO9LeHPFjJaY3miwoMqGHe+ME7OP7WWT02MqUO4Zxngy+bkw1UyiaIbK04Ngzux3mV/Csrehqd0rpw2cj42zY+Xenq+7DtrRs5E5K797efb5LNusQH47JvY2FQIFYtawZy2KJQ34829ZmmC7P3htgNwn+N9wFWBohCdYqAVgEOStD2Y8+bFLXQR8Bq2E+EhdeG0GL8Fr0XKEBPWJpC81bcJR0xgEocwwlEIs5lLHOxLumNuRyjCqwPCtH+PV7pdZl4p7ha+cNdq2qhbXU4ammRqseIpzGNpR7gfm/GWGfN X-Forefront-PRVS: 00808B16F3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN3PR05MB2723;23:3ZwXLOyHVpOxrPUT7CfkAm7cCfWDIa5xQ+ELSgL/N?= =?us-ascii?Q?L+kmZCEQGfppyQu79rVBU+joVq0Nkc8hCu9OiSvYlOp3wmjSZ02G+wd4D9f9?= =?us-ascii?Q?iwcZeSzcFwKC8tEgzRPhWPFru7EYfL07f+g6/ESBgdlyYucg6JpwrUzQS82a?= =?us-ascii?Q?ch5O35Jm75e6RBxXQ+kYpHXdpzzt/6eRzCdSl6RGSo4odvjsZ7CGxKBIK1VJ?= =?us-ascii?Q?N/ARseUGXZao1CyEuhyfPtQ6GdNL9jjjxof5WDgcL3WjoqOmITDUt/uImui8?= =?us-ascii?Q?2tKkNApE1fsFWL6nLSuGAmJjiuK6V8fvSTzKv9g8cy2pCPyrWA96w9Xr8WRg?= =?us-ascii?Q?opCn5zNsdJlxphfbgwoRtqcSfwe3Kw1PVcdHP7WNNgQvUACyEpAE4LRm70zX?= =?us-ascii?Q?hx85C1XuSW1m/9zyWP83Y7vcjE4N8f6K0YMMhKbLdBwrVthBxol1ZstcHZKX?= =?us-ascii?Q?OVvbaLvOc5JG1BRBrFhHabiGa67XLWOZixzz6jm57smP0Wht00EVmmTIUjpF?= =?us-ascii?Q?sEpOuLxS+b9ORrxAAnJgtPlhT2QU/WA35YrFURrdavVg7bktWIPR3jiwzDns?= =?us-ascii?Q?YEnf+F6NWjxi9Nxm/gGPwquaUu5PfYAJiTXvVx+6yc/JtKWdTXzAoCOCR3Dr?= =?us-ascii?Q?Lt/KU7mwiWsZ3pW8QsZ+NOttXx/FQzM2pODmcqtG8ky69oFe9806tvBFqkxl?= =?us-ascii?Q?ziKY+EzIKRjJqBiEPjOWRbgeLjba30RUACRKhcDOHy5GcofZqxvlJqNbe2Km?= =?us-ascii?Q?Fi5v1nIlgC/UfUO1hs7GFoqNQHUYU4aTmFDpO3w+1rUhmGuApWpB18pcnzk0?= =?us-ascii?Q?bAaLRiog2KshvDFtu2FVt0bKrNaUjydNwF1gGQiRcnzqksPPFjMbpkpzR9Om?= =?us-ascii?Q?HTfRflm46tBbwhLE5SQK1ZTQwYKXAeBRt0grV7E6dmNwulDVV2rbiqRVgUpc?= =?us-ascii?Q?Rp0ROOpBaStjtgw7ysp1bc7KXEHmbvVSiZIXKq4f28umU1xLuey54TOFyfQc?= =?us-ascii?Q?P+VMPQ0w22UmOdQB9m4llcisRlsyLiak2wvP9vx0AifrwGWiDLcf8H+bJRNc?= =?us-ascii?Q?wUOft1EXy8wB32ybdrgQBmaNl+kRBdWgGd5BCfhtyAqLQjgD4r86Sb3oldxD?= =?us-ascii?Q?ZNUUmo1MONtlmsWW8E3Ipcstc8XymL7KG/yOfPMDIfiFtRwM94DzQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR05MB2723;6:Y5Y2xlW9z5H4OmcnsbwByXZ8sMi35CJi1h054GTs8zLJmWhtc62pKOxV+/MvaoO9GJwtwGyvfbbGjiWX3lddDOv+povSATob8m7s4ylDUZd2c/SRGekJSSmpNys2lyKmLtbpRjV+kGI1MoQmz/5W7Y8hXYWfjkb/OPCWdivOcTgX+TuIM4Ggw7ovST9wY+VcMZJIMRzoxloSt09jiJnsA/AdyprZrK8qxm++nNh2tnsgeJSTzwZKs4AiJIOXpwYDv8ZTKSwj0Xj3g1RbLyyKhKjR+VjkIMchHw/mkF0QKFifJhFynJIGyNravIqHuhlqUaiMtaksUvGaiR15G2gKPibZJuLWSQ0Iit8BoYfaow4=;5:SNT8Z9A1qyoV+Tbepz+VDInvu+RwhPV1ru0EKgBEoXKJENf4lPY/dq+oyq3grMTMlTOdQF24JUGVNmtYsvSXZRjzq7NClxCamxaIHItr2QtC/O9MNwnQ9SYeTyXFzazHqsVlimnYc7v0i5hWDZT8+Q==;24:50vBFlt0RAscpsb7FbFKFGSZUE3B8YM/Iygrfixq1o74GL0y1+sy41MYk9kKi5d37XkNL2cpTxWm4moKD0tISCwNNsINh+Rl4O3IPHTNkcI=;7:VHsIUWm0hkS8wCnZ8JwZSkJJL9+yaxp+MtOFTJJElz/BisRikz/7k3FCZqmoMMV0KjQS0MJ/zcy2F07mDCLlaMcLb9pCb7ULWMW0MjDqLXfy9j8wPe2AW/1EfpxKB6hFYGg4yeXJMxmrC4xyNEDvswfgmDr/63SPK2S1AW0lur6l1eTLBY4vkFvaq1yhkAd2afqgZ2SNpTn3vs8ubyXesT3i3vezEr7+4RSkQYg2q+xALJaBKcirGAolhkPsoDobCaTVjkTyTdfN4FUN7aN/fUdC5lACqY6u8AThALgUBY1gGyyf48+btgBzF+utrVfl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2016 19:22:57.5958 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.18];Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2723 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi Damien, Damien Miller writes: > On Thu, 29 Sep 2016, Mark D. Baushke wrote: > > Question: > > > > Should RFC 4419 - "Diffie-Hellman Group Exchange for the Secure Shell > > (SSH) Transport Layer Protocol" be deprecated? > > > > Background: > > > > The paper "How to Backdoor Diffie-Hellman" by David Wong > > https://eprint.iacr.org/2016/644.pdf describes two ways > > of creating a Nobody-But-Us (NOBUS) Diffie-Hellman backdoor: > > NOBUS backdoors aren't the only concern; another motivation was > logjam-style precomputation attacks. Yes, the creation of a new set of DH parameters allows us to avoid logjam precomputation attacks against a well known set of DH groups. That said, with NOBUS, how is an SSH client able to identify improper ephemeral DH parameters that have been intesionally weakened? Had RFC4419 sent all three of p,q,g to the client, then the client would may have been able to do more validity checks. However, RFC 4419 does NOT send q AND the methods to select g as given in the RFC is not always going to generate a q-orded subgroup of p. If g is not able to generate a proper q-ordered subgroup value, then concerns of NOBUS arise and in turn means that an attacker may be able to learn the parity of the secret (thus losing only) one bit of security. However, a misconfigured g could also be an indication that there is a NOBUS DH backdoor in the server connection. Moving to the MODP group16 for DH key exchange reduces the ability for a full precomputation logjam type attack. So, I am asking if it is time to deprecate the RFC 4419 kex methods. Failing that, what may be done to enhance a RFC4419bis to handle both logjam and NOBUS attack vectors? Thanks, -- Mark From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 29 22:41:44 2016 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 6C08212B062 for ; Thu, 29 Sep 2016 22:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-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 7-r6pkHTLpMS for ; Thu, 29 Sep 2016 22:41:42 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 C752812B04B for ; Thu, 29 Sep 2016 22:41:42 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 8C10C85EF1; Fri, 30 Sep 2016 05:41: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 BD6F985EEA for ; Fri, 30 Sep 2016 05:41:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id nlbadwRGKyUK for ; Fri, 30 Sep 2016 05:41:39 +0000 (UTC) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by mail.netbsd.org (Postfix) with ESMTP id AEFE384CED for ; Fri, 30 Sep 2016 05:41:36 +0000 (UTC) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8U5fSta039362; Fri, 30 Sep 2016 15:41:28 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id u8U5fS2S055201 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Sep 2016 15:41:28 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id u8U5fRT6013866 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Fri, 30 Sep 2016 15:41:27 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 4247CA4F2E; Fri, 30 Sep 2016 15:41:27 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 390B2A4F07; Fri, 30 Sep 2016 15:41:27 +1000 (AEST) Date: Fri, 30 Sep 2016 15:41:27 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: ietf-ssh@NetBSD.org, curdle@ietf.org, frg@irtf.org Subject: Re: DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors In-Reply-To: <91352.1475176974@eng-mail01.juniper.net> Message-ID: References: <35937.1475160447@eng-mail01.juniper.net> <91352.1475176974@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1475214089 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list On Thu, 29 Sep 2016, Mark D. Baushke wrote: > > NOBUS backdoors aren't the only concern; another motivation was > > logjam-style precomputation attacks. > > Yes, the creation of a new set of DH parameters allows us to avoid > logjam precomputation attacks against a well known set of DH groups. > > That said, with NOBUS, how is an SSH client able to identify improper > ephemeral DH parameters that have been intesionally weakened? I think there's little point - a peer that wants to leak has myraid ways to do so. E.g. it could leak keys via nonces, random padding, DH public values, optional packet padding, etc. Leaking by backdooring DH groups is possibly the worst way to do it - the only reason they can't be properly tested by a client is that its too expensive to do so at connection time. That doesn't mean that it couldn't be done post-hoc or even passively, since the values are sent in the clear (at least for the inital KEX). That's not the case with the other leak paths. E.g. leaking a PRNG seed by encrypting it with a public key and putting it in the KEXINIT nonce is undetectable on the wire and NOBUS as far as you trust your PK crypto. -d From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Thu Sep 29 23:52:45 2016 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 238B412B063 for ; Thu, 29 Sep 2016 23:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=unavailable 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 Oniph2rSEKoC for ; Thu, 29 Sep 2016 23:52:44 -0700 (PDT) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 1FB5212B046 for ; Thu, 29 Sep 2016 23:52:44 -0700 (PDT) Received: by mail.netbsd.org (Postfix, from userid 605) id 0BD9F85F13; Fri, 30 Sep 2016 06:52:43 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id AB3D585F0E; Fri, 30 Sep 2016 06:52:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0A98585F0E for ; Fri, 30 Sep 2016 06:39:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id joAMU1r1ZYl0 for ; Fri, 30 Sep 2016 06:39:23 +0000 (UTC) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id DE8E985E7C for ; Fri, 30 Sep 2016 06:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1475217563; x=1506753563; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R+CDpngbNpQPs7Dqap9Gg1D5r+tAnsB8SgyG3VGf7qA=; b=TJi4AoOzCTz1oxfFf/XH9sEmH1r6VpDiWoFZ2Nfv8c+kbhBLuqISa2yz azFFlDE2QvDG7H1yjI31HdCJchxD/bQXfgpK4nEI1u86rGtfGqkMralj3 HjZJgRxdJHufXWbPmdWCgMhLXbppx0UVMLi470xC1n5hx1vueBc+I2+7I gYK901JjlldoHX0naj7bsExvwQyelLs8Nv89qQ2OCbq707s0dpzOo/cIn szyW+2/5s7rpbQdSV77FOY6yu2U/Qi99S5Ze+xOr75gVe7cBfhe96Bop1 fGcEkhbX6cAc34mmh5cU5SjMfgNzfugX0TWPn0yewyJXJum9h4m75XqkH g==; X-IronPort-AV: E=Sophos;i="5.31,271,1473076800"; d="scan'208";a="108104725" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Sep 2016 19:39:00 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 30 Sep 2016 19:39:00 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::8081:99e3:dee2:203%14]) with mapi id 15.00.1178.000; Fri, 30 Sep 2016 19:39:00 +1300 From: Peter Gutmann To: "Mark D. Baushke" , "ietf-ssh@NetBSD.org" , "curdle@ietf.org" CC: "frg@irtf.org" Subject: Re: [Curdle] DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors Thread-Topic: [Curdle] DH Group Exchange in SSH (RFC 4419) - Avoiding Backsdoors Thread-Index: AQHSGmBugXe6KnFfLEybUJVk/zgfHaCRlcvK Date: Fri, 30 Sep 2016 06:38:59 +0000 Message-ID: <1475217532173.25661@cs.auckland.ac.nz> References: <35937.1475160447@eng-mail01.juniper.net> In-Reply-To: <35937.1475160447@eng-mail01.juniper.net> 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 Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Mark D. Baushke writes:=0A= =0A= >Should RFC 4419 - "Diffie-Hellman Group Exchange for the Secure Shell (SSH= )=0A= >Transport Layer Protocol" be deprecated?=0A= =0A= No.=0A= =0A= If you're worried about a malicious server then you'd really have to deprec= ate=0A= RFCs 4251 to 4253, since only that will protect you from one.=0A= =0A= Peter.=0A=