IETF Logo Mail Archive

Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 14 September 2017 05:45 UTC

Return-Path: <ben@nostrum.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 BD7B3126E64; Wed, 13 Sep 2017 22:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 POxkR0kiMiRg; Wed, 13 Sep 2017 22:45:22 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 78F29128D0F; Wed, 13 Sep 2017 22:45:22 -0700 (PDT)
Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8E5jGrA060827 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Sep 2017 00:45:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <EFE6E580-5561-44EA-B09C-2C335C1FFAEE@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_B4EDB517-F65E-4356-B463-8EB95FF607ED"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 14 Sep 2017 00:45:16 -0500
In-Reply-To: <CADPMZDAe_24e5C_SJaubOW1bGQ7FS_chXS-dTW0jEFY=2ViLfA@mail.gmail.com>
Cc: The IESG <iesg@ietf.org>, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs <curdle-chairs@ietf.org>, curdle <curdle@ietf.org>, draft-ietf-curdle-ssh-ext-info@ietf.org
To: denis bider <denisbider.ietf@gmail.com>
References: <150533102741.30467.13878869431655356929.idtracker@ietfa.amsl.com> <CADPMZDD1ApUzELbNcG-WM3-EoSxGNppWP6mA6FoFr1Ga=a7x8A@mail.gmail.com> <255F9E42-377B-43AF-AFA1-B67C9BC0F714@nostrum.com> <CADPMZDB7nS19=vzkaGa3uKnh4DSxEOVstNhopURLGMrGWXRxYQ@mail.gmail.com> <BCB85BDA-D77B-4493-A6E5-842876BD89E1@nostrum.com> <CADPMZDAe_24e5C_SJaubOW1bGQ7FS_chXS-dTW0jEFY=2ViLfA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/8-M-RVIwHcFloVJt3ZkFWt7BN_8>
Subject: Re: [Curdle] Ben Campbell's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 14 Sep 2017 05:45:24 -0000

> On Sep 14, 2017, at 12:41 AM, denis bider <denisbider.ietf@gmail.com> wrote:
> 
> > One approach might be to say an extension MUST NOT add binary values,
> > but implementations MUST NOT fail if one is present for an extension you
> > don’t understand.
> 
> Unfortunately, prohibiting extensions from having binary extension-values would have significant ramifications that would look very unsightly in the SSH protocol.
> 
> For example, for something like the "delay-compression" extension that needs to encode two name-lists, if extension-value cannot be binary, then it would have to be Base64-encoded. This would be a very questionable choice in a protocol that is otherwise binary and has no reason to pessimize itself this way, other than that one particular implementation, at one point in time, used the wrong function to decode a string. :)

That’s convincing. I will leave this up to the SSH experts to figure out :-)

Ben.

v2.23.0 | Report a Bug | By Email