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

From: Damien Miller <[email-masked]>
Date: Wed, 2 Dec 2015 22:35:18 +1100 (AEDT)

Hi,

Here's some feedback on draft-ssh-ext-info-00.

> 3.1.  Signaling of Extension Negotiation in KEXINIT
...
> 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 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?

> 3.2.  Mechanism Enabling Criteria

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. Initially Defined Extensions
> 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

---

From: Markus Friedl <[email-masked]>
Date: Wed, 2 Dec 2015 15:39:10 +0100

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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 23:14:23 +0000

Markus Friedl <[email-masked]> writes:

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

Doesn't the presence of "rsa-sha2-256" do this?  The client proposes it, and
if the server supports it, they indicate via the algorithm string.  It's
pretty much independent of draft-ssh-ext-info-00 (I know it specifies
"server-sig-algs", but it seems that specifying "rsa-sha2-256" was already
sufficient to indicate this).

Peter.

---

From: Damien Miller <[email-masked]>
Date: Thu, 3 Dec 2015 10:54:26 +1100 (AEDT)

> sufficient to indicate this).

The problem is that, for a client to test whether rsa-sha2-256 is supported,
it must make publickey userauth with an included signature. A
signature free PK_OK style request won't do since the key blob just
contains ssh-rsa and not the signature algorithm.

Making a signature-ful request means unwrapping the private key and,
depending on the implementation, burning an authentication attempt
at the server.

Even then, the client only gets back a USERAUTH_FAILURE that doesn't
indicate whether the attempt was refused because of the key itself,
additional restrictions on the key or because the signature algorithm
is not supported.

-d

---

From: [email-masked] (Niels Möller)
Date: Thu, 03 Dec 2015 09:23:14 +0100

> contains ssh-rsa and not the signature algorithm.

Hmm. This sounds like a serious breakage, and if that's the case, we
really ought to use a new algorithm name also in the key blob.

But is it really so? Looking at RFC 5252, we have

      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name in ISO-10646 UTF-8 encoding [RFC3629]
      string    service name in US-ASCII
      string    "publickey"
      boolean   FALSE
      string    public key algorithm name
      string    public key blob

and

      byte      SSH_MSG_USERAUTH_PK_OK
      string    public key algorithm name from the request
      string    public key blob from the request

I'd expect the "public key algorithm name" to be "ssh-rsa-sha2-256", and
then it's fine if the string inside the keyblob is "ssh-rsa". There's no
ambiguity as to what type of signature is intended.

Regards,
/Niels

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

---

From: denis bider <[email-masked]>
Date: Thu, 3 Dec 2015 08:31:56 +0000

My implementation agrees with Niels's analysis. Even without signature, the signature algorithm name ("rsa-sha2-256") is sent in USERAUTH_REQUEST as "public key algorithm name", followed by public key blob encoding an "ssh-rsa" public key.

No signature is needed to find out whether the server will accept "rsa-sha2-256". If you don't mind making multiple attempts - first "rsa-sha2-256", then "rsa-sha2-512", then "ssh-rsa" - then no extensions are needed to discover which signature algorithms will be accepted; and an actual signature is needed only with the one that will be accepted.

My concern with extensions is removing the trial and error, so that public key authentication with Australia doesn't take 1.5 seconds.

Niels Möller <[email-masked]> , 12/3/2015 8:23 AM:

 

and 

 
Regards, 
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Thu, 3 Dec 2015 09:55:50 +0100

> Am 03.12.2015 um 00:54 schrieb Damien Miller <[email-masked]>:
> 

For PK_OK the format is:
     string pkalg = { ssh-rss | rsa-sha2-512 }
     string keyblob
so the server can tell the difference without having an actual signature.
However, many severs count these PK_OK checks as an authentication
error, so looping over possible signature encodings will break setups.

-m