Subject: Re: Feedback on draft-ssh-ext-info-00

From: Markus Friedl <[email-masked]>
Date: Thu, 3 Dec 2015 10:32:10 +0100

Here is what I've implemented for OpenSSH:

3.  Extension Negotiation Mechanism

3.1.  Signaling of Extension Negotiation in KEXINIT

  Applications implementing this mechanism MUST add to the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:

  - When acting as server: "ext-info-s"
  - When acting as client: "ext-info-c"

  The indicator name is added without quotes, and MAY be added at any
  position in the name-list, subject to proper separation from other
  names as per name-list conventions.

  The names are added to the "kex_algorithms" field because this is one
  of two name-list fields in KEXINIT that do not have a separate copy
  for each data direction.

  The indicator names inserted by the client and server are different to
  ensure that these names will not produce a match, and will be neutral
  with respect to key exchange algorithm negotiation.

  The inclusion of textual indicator names is intended to provide a clue
  for implementers to discover this mechanism.

3.2.  Mechanism Enabling Criteria

  If a client or server offers "ext-info-c" or "ext-info-s"
  respectively, then it must be prepared to accept a SSH_MSG_EXT_INFO
  message from the peer.

  Thus a server only needs to send "ext-info-s" if it intends to
  process SSH_MSG_EXT_INFO from the client.

  If a server receives an "ext-info-c", then it can send a
  SSH_MSG_EXT_INFO message, but it's not required to do so.

  If a SSH_MSG_EXT_INFO message is sent, then it MUST be the first
  message after the initial SSH_MSG_NEWKEYS.

  This way a server will send the SSH_MSG_EXT_INFO before sending
  a possible SERVICE_ACCEPT message.

  Implementations MUST NOT send an incorrect indicator name for their
  role. Implementations MAY disconnect if the counter-party does so.
  If an indicator name ("ext-info-c" or "ext-info-s") ends up being
  negotiated as a key exchange method, the parties MUST disconnect.

3.3.  Indicating Extensions

  A party that received the "ext-info-c" or "ext-info-s" indicator
  can send the the following message:

    byte       SSH_MSG_EXT_INFO (value 7)
    uint32     nr-extensions
    repeat "nr-extensions" times:
      string   extension-name
      string   extension-value

  This message is sent without delay, and immediately after
  SSH_MSG_NEWKEYS.

3.4.  Interpretation of Extension Names and Values

  Each extension is identified by its extension-name, and defines the
  conditions under which the extension is considered to be in effect.
  Applications MUST ignore unrecognized extension-names.

  Extension-value fields are interpreted as defined by their respective
  extension. An extension-value field MAY be an empty string if so
  permitted by the extension. Applications that do not implement
  or recognize a particular extension MUST ignore the associated
  extension-value field, regardless of its size or content.

  The cumulative size of an SSH_MSG_EXT_INFO message is limited only by
  the maximum packet length that an implementation may apply in
  accordance with [RFC4253]. Implementations MUST accept well-formed
  SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.

4. Initially Defined Extensions

4.1. "server-sig-algs"

  This extension is sent with the following extension name and value:

    string      "server-sig-algs"
    name-list   signature-algorithms-accepted

  Note that the name-list type is a strict subset of the string type,
  and is thus permissible as an extension-value.

  This extension is sent by the server only, and contains a list of
  signature algorithms that the server is able to process as part of a
  "publickey" authentication request.

  A client that wishes to proceed with public key authentication MAY
  wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey"
  authentication request with an appropriate signature algorithm, rather
  than resorting to trial and error.

  Servers that implement public key authentication SHOULD implement this
  extension.

  If a server does not send this extension, a client SHALL NOT make any
  assumptions about the server's signature algorithm support, and MAY
  proceed with authentication request trial and error.

---

From: [email-masked] (Niels Möller)
Date: Thu, 03 Dec 2015 13:51:19 +0100

> Here is what I've implemented for OpenSSH:

Looks nice and simple to me.

The trick of adding foo-s and foo-c symbols to the kex_algorithms list
could perhaps be reused in case we need to negotiate support for aead, to
enable different rules for algorithm negotiation (including the rules
for first_kex_packet_follows).

>     name-list   signature-algorithms-accepted

I still question the utility of this extension. I would expect the common
case will be a large list of algorithms, and the the client needs to
send a PK_OK request for each key it has anyway.

But I don't object to it if others find it useful.

Maybe "userauth-sig-algs" or "publickey-algs" is a better name, to make
it clearer that it is related to publickey userauth.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Markus Friedl <[email-masked]>
Date: Thu, 3 Dec 2015 01:46:08 +0100

> Am 03.12.2015 um 01:21 schrieb denis bider <[email-masked]>:
> 
> 
> Sounds good. Can you post a writeup of the scheme you implement?
> 
> It doesn't have to be an Internet-Draft, just something better than reverse engineering source code.
> 

I've implemented it exactly as Damien has specified it in his mail.

-m

---

From: denis bider <[email-masked]>
Date: Thu, 3 Dec 2015 00:21:13 +0000

*blush* :)

(A spec might not only make things easier for others, but also improve the implementation. I find that writing things down helps call to mind corner cases I would have ignored otherwise.)

----- Original Message -----
From: Markus Friedl 
Sent: Wednesday, December 2, 2015 08:39
To: [email-masked] 
Cc: Damien Miller 
Subject: Re: Feedback on draft-ssh-ext-info-00

I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and
welcome a way for signaling SHA2 support to the client for userauth,
especially since I'm sabotaging protocol extensions with the strict
message format checks I've added to OpenSSH before.

However, I also agree with Damien that the suggested proposal seems
unnecessary complex to me and will try to implement the simpler
scheme he suggests.

-m

> Am 02.12.2015 um 12:35 schrieb Damien Miller <[email-masked]>:
> 
> Hi,
> 
> Here's some feedback on draft-ssh-ext-info-00.
> 
> ...
>> names as per name-list conventions. The suggested position is last in
>> the list, but implementations MUST recognize these indicator names
>> when included at any position.
> 
> IMO it would be best to make it a MUST that the flags may only be
> sent as the last element. What rationale is there for putting it
> anywhere else?
> 
> This whole section seems over-complicated. I think a simpler scheme
> is:
> 
> If a client or server offers "ext-info-c" or "ext-info-s" respectively,
> then it must be prepared to accept a SSH_MSG_EXT_INFO message from the
> peer. 
> 
> If this message is sent, then it will be the first message after the
> initial SSH_MSG_NEWKEYS.
> 
> I.e. make it a simple advertisment that a client or server is willing
> to accept a notification message that might optionally be sent.
> Don't require both sides to offer acceptance, don't have the messages
> offer any sort of negotiation between the client and server (just
> statements of extensions/capabilities) and don't "replace" any
> messages like SSH_MSG_SERVICE_REQUEST.
> 
> This would yield a much simpler specification IMO.
> 
>> 4.2.  "client-req-ok"
> I don't see the point of this: implementations that don't respond with
> SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are
> incompliant with RFC4254 section 4.
> 
> OpenSSH has sent various @openssh.com global requests for years,
> so most of the implementations that violate this should have long since
> been shaken out.
> 
>> 4.3.  "no-handbrake"
> 
> This could be implemented more elegantly using new channel type names
> in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and
> inflexible method proposed here (e.g. it's impossible to have one
> channel without the "handbrake" and one with normal flow control).
> 
> It would be better to use the extension to signal that the
> peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel
> type names, and use these to selectively disable flow control.
> 
> Given this, IMO this would be better off being replaced by a generic
> "these are the channel types I'm prepared to open" message, which would
> be useful even for implementation that don't want to turn off flow control
> but which do implement non-standard channel types (e.g. [email-masked]).
> 
> -d
>