Subject: [Curdle] RFC 8308 on Extension Negotiation in the Secure Shell (SSH) Protocol

From: [email-masked]
Date: Mon, 19 Mar 2018 15:23:14 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 8308

        Title:      Extension Negotiation in the 
                    Secure Shell (SSH) Protocol 
        Author:     D. Bider
        Status:     Standards Track
        Stream:     IETF
        Date:       March 2018
        Mailbox:    [email-masked]
        Pages:      14
        Characters: 29204
        Updates:    RFC 4251, RFC 4252, RFC 4253, RFC 4254

        I-D Tag:    draft-ietf-curdle-ssh-ext-info-15.txt

        URL:        https://www.rfc-editor.org/info/rfc8308

        DOI:        10.17487/RFC8308

This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a
mechanism for Secure Shell (SSH) clients and servers to exchange
information about supported protocol extensions confidentially after
SSH key exchange.

This document is a product of the CURves, Deprecating and a Little more Encryption Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 20 Mar 2018 09:40:33 +0000

>                    Secure Shell (SSH) Protocol

Are there any publicly-accessible servers running this that can be used for interop testing?

Peter.

---

From: denis bider <[email-masked]>
Date: Tue, 20 Mar 2018 19:14:44 -0500

That depends - which extensions do you have in mind to test? In what way in
particular would you like to test them?

If you are looking for "server-sig-algs", this is by now fairly widely
implemented in e.g. the latest versions of OpenSSH, and Bitvise SSH Server
and Client versions 7.xx.

If you are looking for "delay-compression", "no-flow-control" and
"elevation", these are implemented in the current Bitvise SSH Server
development version which we plan to release as version 8.xx. I can make
this available if you would like to test one of these extensions.

denis

On Tue, Mar 20, 2018 at 4:40 AM, Peter Gutmann <[email-masked]>
wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 21 Mar 2018 05:48:57 +0000

>particular would you like to test them?

It was actually meant for both of the new RFCs, the RSA one to regression-test
that nothing has broken since versions based on the drafts were written (e.g.
in regard to fixed- vs variable-length RSA blocks :-), the extension one just
to check that extensions sent and received are correctly handled without
anything choking.  The actual extension doesn't matter, just the message flow
handling.

>and Client versions 7.xx.

OK, I'll see if I can set up a recent OpenSSH to bounce some messages off.  I
just want to make sure that both RSA and extension messages are handled
correctly.

Peter.

---

From: denis bider <[email-masked]>
Date: Thu, 22 Mar 2018 04:03:15 -0500

EXT_INFO with the "server-sig-algs" extension is widely deployed. It's well
tested with rsa-sha2-256 and rsa-sha2-512 signatures, and I have no
concerns about it. As far as I know, there are no compatibility issues to
be experienced by an implementation that follows the just-published spec.

Where I'm less comfortable is the hinges that are not yet widely deployed.
As long as a hinge is not in common use, it is in danger of rusting. These
hinges include:

- EXT_INFO sent by client (only server sends it for "server-sig-algs").

- Extensions with binary extension-value (for example "delay-compression").

Both of these hinges will be exercised in our next SSH Server and Client
versions (8.xx). However, our implementation has presence on only one
platform, so I would love to see "delay-compression" implemented more
widely so that these hinges do not rust.

This hinge did already rust in the initial implementation by OpenSSH
(binary extension-value caused disconnect until version 7.5).

"delay-compression" involves both client-side EXT_INFO and a binary
extension-value, so it is the single most effective thing to implement to
avoid rust.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Mar 2018 10:13:40 +0000

denis bider <[email-masked]> writes:

>Where I'm less comfortable is the hinges that are not yet widely deployed. As
>long as a hinge is not in common use, it is in danger of rusting. These hinges
>include:
>

I was going to try sending in extensions with undefined values, and binary
data embdded in them, to see what happens.  If it's the same as previous, in
some instances inadvertent, cases of sending unexpected data values then I
expect all sorts of fireworks.

>tested with rsa-sha2-256 and rsa-sha2-512 signatures, and I have no concerns
>about it. As far as I know, there are no compatibility issues to be
>experienced by an implementation that follows the just-published spec.

OK, that's good to know.

Peter.

---

From: denis bider <[email-masked]>
Date: Thu, 22 Mar 2018 06:55:14 -0500

Those sound like good ideas. I would like more people to try that. :)

If you want to test with Bitvise SSH Server, you can download it free of
charge from our website. It's easy to set up if you have a Windows
computer. You can also access it already set up here:

Host: experiment.bitvise.com
Port: 10739
User: test
Pass: test

If you want to test RSA authentication, the server will provide
instructions in the SSH authentication banner, or you can find them in
Welcome.txt after you are logged in.

If you want to test Bitvise SSH Client, you can also download it free of
charge from our website. It can be used free of cost in any environment.
You just need a Windows installation.

The real juice however would be in testing other implementations. I would
suggest setting up and trying the latest OpenSSH versions, both server and
client.

On Thu, Mar 22, 2018 at 5:13 AM, Peter Gutmann <[email-masked]>
wrote:

> concerns

---

From: denis bider <[email-masked]>
Date: Thu, 22 Mar 2018 06:58:44 -0500

To be sure, the latest OpenSSH version is 7.6. I know that versions up to
7.5 will disconnect on receiving binary extension-values. Fortunately
OpenSSH makes it easy to identify itself, so we have a workaround for that
(not sending "delay-compression" to OpenSSH 7.5 and older, which does not
support "delay-compression" anyway).