draft-ssh-ext-info-05 available
denis bider <ietf-ssh3@denisbider.com> Sun, 20 December 2015 14:33 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 CB0101B2DA0 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 20 Dec 2015 06:33:09 -0800 (PST)
X-Quarantine-ID: <Bf6QJ1wywyKd>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary; ; error: unexpected end of parts before epilogue
X-Spam-Flag: NO
X-Spam-Score: 1.09
X-Spam-Level: *
X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf6QJ1wywyKd for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 20 Dec 2015 06:33:08 -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 7CC571B2D9F for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sun, 20 Dec 2015 06:33:08 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id D460784CE8; Sun, 20 Dec 2015 14:33:06 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 91AE684CE7; Sun, 20 Dec 2015 14:33:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5DA4385EEB for <ietf-ssh@netbsd.org>; Fri, 18 Dec 2015 06:16:58 +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 EzFzqB4YQzlY for <ietf-ssh@netbsd.org>; Fri, 18 Dec 2015 06:16:57 +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 DD35585EE5 for <ietf-ssh@netbsd.org>; Fri, 18 Dec 2015 06:16:57 +0000 (UTC)
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com for nisse@lysator.liu.se; Fri, 18 Dec 2015 06:16:51 +0000
Date: Fri, 18 Dec 2015 06:16:51 +0000
Subject: draft-ssh-ext-info-05 available
X-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Message-ID: <783754389-3212@skroderider.denisbider.com>
X-Priority: 3
Importance: Normal
MIME-Version: 1.0
From: denis bider <ietf-ssh3@denisbider.com>
To: Niels Möller <nisse@lysator.liu.se>, Matt Johnston <matt@ucc.asn.au>, Damien Miller <djm@mindrot.org>, Markus Friedl <mfriedl@gmail.com>
Cc: ietf-ssh@netbsd.org
Content-Type: multipart/alternative; boundary="=-iUk8+3ZaauQQnHMS6IC5"
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list
I have submitted a new version of the SSH_MSG_EXT_INFO draft: https://tools.ietf.org/html/draft-ssh-ext-info-05 Changes: - New extension: "elevation". This is useful when connecting to Windows servers where the SSH server needs to know at the time of creating the logon session whether the client wants the session to be elevated or not. - New extension: "delay-compression". This is a generic mechanism for enabling delayed compression whose main goal is to fix the race condition inherent in zlib@openssh.com. I would like to make the following change, but cannot unless this can be agreed by Markus and/or Damien: - Matt Johnston, Niels Möller, and myself have expressed a preference for mandating the following behavior: Matt: Why not [...] 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. The spec currently dictates this instead: Markus: If a client or server offers "ext-info-c" or "ext-info-s" respectively, it must be prepared to accept a SSH_MSG_EXT_INFO message from the peer
- draft-ssh-ext-info-05 available denis bider