Post-user-auth compression as an extension? (Re: Feedback on draft-ssh-ext-info-00)
denis bider <ietf-ssh3@denisbider.com> Mon, 14 December 2015 19:08 UTC
Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937DD1B2DB1 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 14 Dec 2015 11:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.209
X-Spam-Level:
X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjPJWxR--JES for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Mon, 14 Dec 2015 11:08:14 -0800 (PST)
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 743871B2DB6 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Mon, 14 Dec 2015 11:08:09 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id 126CD85EA8; Mon, 14 Dec 2015 19:08:09 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id C179E85EA1; Mon, 14 Dec 2015 19:08:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id E525D85E68 for <ietf-ssh@netbsd.org>; Mon, 14 Dec 2015 00:53:36 +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 2yav7k8vH5ye for <ietf-ssh@netbsd.org>; Mon, 14 Dec 2015 00:53:36 +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 3548685E4A for <ietf-ssh@netbsd.org>; Mon, 14 Dec 2015 00:53:36 +0000 (UTC)
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for matt@ucc.asn.au; Mon, 14 Dec 2015 00:53:25 +0000
Date: Mon, 14 Dec 2015 00:53:25 +0000
Subject: Post-user-auth compression as an extension? (Re: Feedback on draft-ssh-ext-info-00)
X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Message-ID: <422177518-2040@skroderider.denisbider.com>
X-Priority: 3
Importance: Normal
MIME-Version: 1.0
From: denis bider <ietf-ssh3@denisbider.com>
To: Matt Johnston <matt@ucc.asn.au>, Niels Möller <nisse@lysator.liu.se>, Damien Miller <djm@mindrot.org>, Markus Friedl <mfriedl@gmail.com>
Cc: ietf-ssh@netbsd.org
Content-Type: multipart/alternative; boundary="=-8mfort3DKpwa7UzIh1Et"
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list
> Regarding the secondary SSH_MSG_EXT_INFO before > SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server > can't tell if subsequent packets it receives were sent by the > client prior to receiving SSH_MSG_EXT_INFO It seems to me that resolving this race condition in a generic manner requires an acknowledgment from the client that it has received the second SSH_MSG_EXT_INFO. However, it seems weird to be defining such an acknowledgment for hypothesized extensions, without a known extension using it. But perhaps we should define such an extension. :-) How about defining an extension for negotiation of post-user-auth compression? That would: - Allow the client and server to avoid re-doing key exchange, which is currently required for safe implementation of the popular post-user-auth compression scheme. - Allow for the server to avoid advertising it supports compression to unauthenticated clients. - Provide a specific case to justify the client sending an acknowledgment that it has received SSH_MSG_EXT_INFO. ----- Original Message ----- From: Matt Johnston Sent: Friday, December 11, 2015 09:31 To: Niels Möller Cc: denis bider ; Damien Miller ; Markus Friedl ; ietf-ssh@netbsd.org Subject: Re: Feedback on draft-ssh-ext-info-00 > On Fri 11/12/2015, at 4:39 pm, Niels Möller <nisse@lysator.liu.se> wrote: > ... > Since the protocol is specified as running over a byte stream, we ought > not to reason in terms of the EXT_INFO arriving in the same packet as > the NEWKEYS, even if that probably would work in practice. > > To remove the ambiguity, negotiation has to be a bit more complex. > We'd need four more magic symbols, > > ext_info_{send,recv}_{c,s} > > and specify that the server MUST send EXT_INFO if and only if the > client advertised ext_info_recv_c and the server advertised > ext_info_send_s. Why not keep just ext_info_{c,s} and specify that client and server both MUST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both sent ext_info_{c,s}? Then they both know what to expect. Regarding the secondary SSH_MSG_EXT_INFO before SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server can't tell if subsequent packets it receives were sent by the client prior to receiving SSH_MSG_EXT_INFO - the same as the delayed zlib race [1]. Probably won't be a problem for the current extensions but it could cause trouble if it's used for transport-level extensions. I think "server-sig-algs" should have "auth" somewhere in the name to avoid confusion with hostkey algorithms. Not a huge deal. As a small data point Dropbear client has been sending SERVICE_REQUEST and USERAUTH_REQUEST in the same TCP packet since 2013 (2013.57) with no reports of problems. That said Dropbear is a lot more widely used as a server than client - I'm sure there could be something that wouldn't handle it. FWIW Dropbear is already using the kex algorithm "kexguess2@matt.ucc.asn.au" to signal more permissive first_kex_packet_follows negotiation. [2] Cheers, Matt [1] Simon's comment http://thread.gmane.org/gmane.ietf.secsh/6108/focus=6110 [2] http://www.ietf.org/mail-archive/web/secsh/current/msg00657.html
- Post-user-auth compression as an extension? (Re: … denis bider
- Re: Post-user-auth compression as an extension? (… Niels Möller