[Curdle] Fwd: Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
denis bider <denisbider.ietf@gmail.com> Wed, 29 April 2020 17:44 UTC
Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3863A14C5 for <curdle@ietfa.amsl.com>; Wed, 29 Apr 2020 10:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poY-vL1eln5K for <curdle@ietfa.amsl.com>; Wed, 29 Apr 2020 10:44:01 -0700 (PDT)
Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A45E3A14CA for <curdle@ietf.org>; Wed, 29 Apr 2020 10:44:01 -0700 (PDT)
Received: by mail-oo1-xc35.google.com with SMTP id e18so617456oot.9 for <curdle@ietf.org>; Wed, 29 Apr 2020 10:44:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iQuUseg/2FnkmVxRqM3IwtjZkvYOK+1sA5/X5zW7PXc=; b=RGDRkPa55w8tFF39JP2p2KS6hK+S0wwYzo02r33Z7osDdtpWFlNmrcM3u6MP30PjKS UKPFUu0q4kow1sCDVupMBNovARNGc6DrwNuQuuMwQcwN/eLS0aWyu89EXJCX9pMudkfy qA9AxeuOtz/cGykRY5LF1JNQaQv6z9gemNcs3RQ4+gsBKbGplnmAYhJLOVQUP2BR3Lak QShBw4et7SS3NHbPvcgh7rq1lTcBmOxwrvoGCXDjPpEaxYkSYnVLxn+ZHF45mUyYZ2aA Zk0r3M417SMJy/Sn4JKX1ck9iwuWCWneynOrx+x1E0yB2N2G9bjCwkSmUcwM/YAU4qWw LTQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iQuUseg/2FnkmVxRqM3IwtjZkvYOK+1sA5/X5zW7PXc=; b=FcSDtnqU85F06uBU353DfdGZ8oFfc5NZi042ZFxBxLS3d7qYffLi0shbxxEkZcUIMX qyeLzapBRFWIHrNti/Gf4qY2UFQP1BDnzIdoqGD5GlTKY7/q4wJoFP6coYEvZ1O6TBrU GX4e7ER3Ag/OUsEEy9+1CR8+WZaQqQT1Ej4fzO/3nHM+vhAxE0j4iPeQ+7nhXBlGH8b3 8HCFY7F1C//HCmIlQkgglJeEzIcdM4eWpMUDNgvOuIN+tVmSqDFjm+je214LfqjPcRRc cZp1YaC8IIKkix+e1F5pvZ6IKvGd6HgUVFKRFolR5HMLl1mkBdstEqwSnua72puyzjWr FtIA==
X-Gm-Message-State: AGi0PuYYOCxuFMkoJhWcUMyFduDD2MMLBEJBU6B6nEXrXuXoXqoct1i6 2C2f1ZhI2Xn5I9wcYBh2m8ULpFSLE9HwlSo6p4GMHCjd
X-Google-Smtp-Source: APiQypJ/rq5enVPHhUsbJpV5ogwJr7X4wP5uTdg+sFHRQfYPGNNUhras9gx5b+qq4vuQ8KLEzWlnPLHasF50ed8GfbI=
X-Received: by 2002:a4a:5747:: with SMTP id u68mr28534917ooa.32.1588182240351; Wed, 29 Apr 2020 10:44:00 -0700 (PDT)
MIME-Version: 1.0
References: <CADPMZDB6rfM7mFOgicNxAanKcuB5yfdnJGy_jNtZDV3PKoqCZw@mail.gmail.com>
In-Reply-To: <CADPMZDB6rfM7mFOgicNxAanKcuB5yfdnJGy_jNtZDV3PKoqCZw@mail.gmail.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Wed, 29 Apr 2020 12:43:49 -0500
Message-ID: <CADPMZDBPdMHvKBc3wnhNZtO3d4W-kTa_RVc66Wh_s62XrK-p-g@mail.gmail.com>
To: curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046596b05a4717e2f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/RiaYmAHdmjfsISR8lH0MqOyGiT4>
Subject: [Curdle] Fwd: Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2020 17:44:04 -0000
Forwarding my below response because it's relevant to previous discussion here. It's worth noting the copy of the message sent directly to Mouse was rejected by his mail server as follows: 550 I don't accept mail from spammers like Google. (See ftp.rodents-montreal.org:/mouse/misc/google-block.txt for the story.) So... that's a statement a particular implementor makes about compatibility. :) If you reject email from Google, that's a legitimate design philosophy, but it's not one most people would agree with in practice. ---------- Forwarded message --------- From: denis bider <denisbider.ietf@gmail.com> Date: Wed, Apr 29, 2020 at 12:36 PM Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle! To: <mouse@rodents-montreal.org>, <ietf-ssh@netbsd.org> > Broken software will probably always be with us. That's theoretically true but practically unhelpful. :) In practice, it matters how much broken software there is. One obscure implementation failing at something is a minor issue, but one major one or several minor ones means a practical implementation which aims for widespread compatibility can't use the feature. Therefore it's important to exercise the protocol abilities we want to preserve to keep the number of broken implementations low, rather than high. > Speaking of which, and I recognize it's possible nobody > here is in a position to answer this, why does EXT_INFO > exist, rather than just using the DNS extensibility > mechanism, with global requests if necessary? I do believe I'm in a position to answer this. I offer two reasons, one from each category: (I) Reason of principle: before EXT_INFO, the SSH protocol lacked extensibility beyond that permitted by adding individual algorithms, without raising the protocol version number. Changing the protocol version number is incompatible with current widespread deployment. In the interest of future extensibility, a generic extension mechanism was needed which is fully compatible with the installed base that does not support it. This is a SSH-specific instantiation of a generic need for extension negotiation that has identified by most popular internet protocols. ESMTP has this, FTP has this, TLS has this, even SFTP has this. Now SSH has it. It fills a retroactively obvious gap that wasn't covered previously. (II) Reason of practical need: SSH needed to transition from RSA signatures with SHA-1 to RSA signatures with SHA-2. This could have been done without EXT_INFO by creating a new key format, but then all existing host key and client public key associations would break, and it would take a decade and lots of difficulty and coaxing to upgrade users. To preserve existing host key and client public key associations, it was desirable to preserve the same public key format ("ssh-rsa") but introduce new signature algorithms ("rsa-sha2-256" and "rsa-sha2-512"). But now there's a problem - during client authentication, the client needs to discover which signature algorithms the server supports without risking a lockout due to an authentication penalty. So the server needs some way to announce this. It would have been possible to come up with an ad-hoc kludge mechanism specific for this, but then this would cost us 1 kludge and it would gain only 1 solution. Instead, I thought it was desirable to expend the cost of this kludge, and gain instead a general solution. EXT_INFO is this general solution. It solves the problem of advertising RSA signature algorithms supported by the server, while at the same time adding a extension negotiation to SSH. So now we have this one kludge (it works by adding "ext-info-c" or "ext-info-s" to a KEXINIT field not originally intended for this), but we gain a general extension mechanism so that, IF WE DON'T LOSE IT, we don't need any more kludges in the future. Why not DNS...? Because the extension mechanism in a protocol should be self-contained. I mean, it would be possible for FTP, ESMTP, TLS or SFTP to have an extension mechanism based on DNS, yes - in principle. Does that seem a good idea to anyone...? It seems an obvious can of worms to me. denis
- [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or … denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Ron Frederick
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Peter Gutmann
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider
- [Curdle] Fwd: Client-side SSH_MSG_EXT_INFO: Use i… denis bider
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… Ron Frederick
- Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it… denis bider