[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>rg>, <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