IETF Logo Mail Archive

Re: Updated EXT_INFO draft - draft-ssh-ext-info-02

nisse@lysator.liu.se (Niels Möller ) Tue, 15 December 2015 08:32 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 B83AC1A0021 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Tue, 15 Dec 2015 00:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 0Vij7p6r26CO for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Tue, 15 Dec 2015 00:32:20 -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 A769A1A001D for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Tue, 15 Dec 2015 00:32:20 -0800 (PST)
Received: by mail.netbsd.org (Postfix, from userid 605) id 7441385E66; Tue, 15 Dec 2015 08:32:19 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A672D85E63 for <ietf-ssh@netbsd.org>; Tue, 15 Dec 2015 08:32:17 +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 PtbP91N61AHI for <ietf-ssh@netbsd.org>; Tue, 15 Dec 2015 08:32:17 +0000 (UTC)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 F21F985E5C for <ietf-ssh@netbsd.org>; Tue, 15 Dec 2015 08:32:15 +0000 (UTC)
Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6FEA3400A7; Tue, 15 Dec 2015 09:32:12 +0100 (CET)
Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id 9C48940033; Tue, 15 Dec 2015 09:32:10 +0100 (CET)
Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Tue, 15 Dec 2015 09:32:10 +0100
From: nisse@lysator.liu.se
To: denis bider <ietf-ssh3@denisbider.com>
Cc: Damien Miller <djm@mindrot.org>, Markus Friedl <mfriedl@gmail.com>, ietf-ssh@netbsd.org
Subject: Re: Updated EXT_INFO draft - draft-ssh-ext-info-02
References: <1634365300-2152@skroderider.denisbider.com>
Date: Tue, 15 Dec 2015 09:32:10 +0100
In-Reply-To: <1634365300-2152@skroderider.denisbider.com> (denis bider's message of "Thu, 3 Dec 2015 01:51:01 +0000")
Message-ID: <nnr3iojenp.fsf@armitage.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: ClamAV using ClamSMTP
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

denis bider <ietf-ssh3@denisbider.com> writes:

> (3) "Don't replace SERVICE_REQUEST + ACCEPT"
>
> I still believe SERVICE_REQUEST + ACCEPT serve no purpose, and waste a
> round-trip for no reason. 

I still fail to see why SERVICE_REQUEST costs a roundtrip time. IIRC,
you claimed or guessed that some implementations can't handle NEWKEYS +
SERVICE_REQUEST + UERAUTH_REQUEST sent back-to-back. But I don't think
I've seen any details. And I really don't think replacing
SERVICE_REQUEST is an appropriate or proportionate workaround for such
bugs.

> This seems like a great opportunity to do away with them.

It's fine to have a proposed change to replace SERVICE_REQUEST depend on
the proposed extension mechanism. But please don't introduce a reverse
dependency. 

I don't think there's likely to be consensus that we should do anything
about SERVICE_REQUEST now, so it's going to be an obstacle to the
extension mechanism which is a lot easier to agree on.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

v2.23.0 | Report a Bug | By Email