Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

[denis bider <ietf-ssh3%denisbider.com@localhost>]

(1) I have uploaded a new version of the RSA SHA-2 draft:

https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-02

Changes:

- Based on feedback from Peter, now again includes rsa-sha2-256 as RECOMMENDED.
- rsa-sha2-512 is now OPTIONAL.
- The signature algorithm discovery method described in -01 is removed. Instead:


(2) I have written a new draft for a general SSH Extension Negotiation mechanism:

https://tools.ietf.org/html/draft-ssh-ext-info-00

Summary:

* Special indicator names are included in KEXINIT to indicate support for this mechanism.

I have looked at alternatives, but:
- libssh handles the KEXINIT reserved field incorrectly (ignores actual value, so key exchange fails if it's not zero)
- I'm hesitant to increase the protocol version number for a change that does not affect security, and does not touch KEXINIT, or affect key exchange
- Fields cannot be added to existing packets without negotiation, due to reasons discussed previously (implementations take a restrictive view of packet formats)

* If both parties indicate support for extension negotiation, the SERVICE_REQUEST and SERVICE_ACCEPT messages are replaced with a new message, SSH_MSG_EXT_INFO.

This is more useful than SERVICE_REQUEST, and saves at least half a round-trip because the server sends EXT_INFO immediately, and does not wait for client.

* The EXT_INFO message contains a list of name-value pairs, each identifying an extension and optional parameters.

* Three extensions are defined upfront:

server-sig-algs: Allows efficient discovery of signature algorithms supported by the server. For public key authentication, the client only needs to wait for the EXT_INFO message sent by the server. This should arrive half a round-trip sooner than SERVICE_ACCEPT. The client can then immediately send a public key authentication request with an appropriate signature method.

client-req-ok: Allows clients to affirm that the server can send a global request (especially an unrecognized global request) without risking the client disconnecting. This should be supported by all clients. It is necessary so that servers can enable active keep-alive, which is not otherwise possible generally because some clients do disconnect when they receive a global request.

no-handbrake: Peter ought to like this. :) A few years late, but this makes window size infinite for both directions in a channel, at the cost of restricting the session to one simultaneous channel. This should help file transfer applications for which the channel flow control in SSH is an impediment, rather than a feature.

If you guys like this, then - if anyone else has an extension they would like to add, now might be the time to define them!

denis