Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

["denis bider \(Bitvise\)" <[e-mail]>]

Peter:


> I was thinking of it in terms of SSL's Change Cipherspec,
> the same as SSH's Newkeys, where there's all sorts of
> subtle problems if you send data before getting the other
> side's CCS to confirm that both sides are using the same
> crypto parameters.

Can you point out some of these subtle problems that could occur in this 
regard in SSH?


> So the point of the SSH_MSG_SERVICE_REQUEST wasn't so much
> getting back the "yeah, sure, whatever" response from the
> server, it was being able to verify that you could decrypt
> and MAC the response you got.

If that was a primary purpose, rather than a side effect, I imagine there 
would be an SSH_MSG_NEWKEYS_VERIFY, which would be encrypted with the new 
crypto parameters. This could be sent immediately after SSH_MSG_NEWKEYS, 
which is the last message that uses old parameters.

But yes, it's possible this is a desired side effect. In this case, if the 
server sends EXT_INFO immediately after NEWKEYS, and client wants to wait 
for a successful encrypted packet before queueing up an authentication 
request; this lets the client queue up the authentication request faster, 
because it doesn't have to wait for SERVICE_ACCEPT. Instead, the server's 
EXT_INFO already serves this role.

The server's EXT_INFO doesn't contain confidential information (client is 
not authenticated), so there is no problem there.

This leaves the situation that the client may be sending its own EXT_INFO 
after NEWKEYS. Perhaps an extension will be defined where the client would 
send info here it doesn't want to make public. (Currently, I don't know of 
one.)

Under the assumption that such an extension were defined, can you point out 
at least one way that sending this info right after NEWKEYS can help an 
attacker?


> > 2. Send SERVICE_REQUEST, immediately followed by a USERAUTH
> > message. This can all be sent potentially in the same
> > transmission as the client's NEWKEYS.
>
> Ugh. So there are implementations that will send a NEWKEYS +
> SERVICE_REQUEST + USERAUTH all in one block without having
> any idea wheteher the crypto handshake process has succeeded?

It is possible. However, I'm not aware that an implementation actually does 
this. Ours waits for SERVICE_ACCEPT. I checked three others; they wait too.


> > string  "no-flow-control"
> > string  choice of: "p" for preferred | "s" for supported
>
> So you really just need at least one side to set a boolean
> flag saying "yes, I really want this".  In other words
> no-flow-control + boolean = false says the option is
> available, and boolean = true says you must enable the option.

Yes. But the extension value field is generically a string (it must be same 
type for all extensions, so unsupported extensions can be decoded and 
ignored). "p" and "s" are therefore fitting ways to express this boolean.


This week, I implemented "no-flow-control" in our software (in the manner 
recently defined - using "p" to indicate preferred, and "s" for supported). 
It works, but I point out that testing indicates zero performance benefit 
between our SSH Client and Server. In other words, regular SSH flow control 
has no handbrake effect if it's done right.

The main advantages I see with this extension are:

- In 10 years: it could become widely supported, and new simpler SSH 
software that only needs one channel can avoid complexity, and never 
implement SSH flow control.

- Right now: authors who are having trouble with their window adjusting can 
sidestep that by implementing "no-flow-control" in addition.

Properly implemented flow control is superior. However, this extension is a 
nod to that not everyone will be using an SSH library that does this right, 
and "no-flow-control" is a better option if your needs are simple, and you 
don't have a few years to get this right.

denis


----- Original Message -----
From: Peter Gutmann
Sent: Saturday, March 25, 2017 04:02
To: denis bider (Bitvise) ; Daniel Migault ; curdle
Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info

denis bider (Bitvise) <[e-mail]> writes:

>I'm not sure that I see the threat here, or how the described behavior 
>would
>resolve it.

I was thinking of it in terms of SSL's Change Cipherspec, the same as SSH's
Newkeys, where there's all sorts of subtle problems if you send data before
getting the other side's CCS to confirm that both sides are using the same
crypto parameters.  I'd always assumed that SSH's use of the redudant
SSH_MSG_SERVICE_REQUEST followed by a SSH_MSG_USERAUTH_REQUEST was that you
checked that the SSH_MSG_SERVICE_REQUEST succeeded, in other words that both
sides had scuccessfully agreed on the same crypto parameters, before sending
sensitive data in the SSH_MSG_USERAUTH_REQUEST.  So the point of the
SSH_MSG_SERVICE_REQUEST wasn't so much getting back the "yeah, sure, 
whatever"
response from the server, it was being able to verify that you could decrypt
and MAC the response you got.

>2. Send SERVICE_REQUEST, immediately followed by a USERAUTH message.
>
>This can all be sent potentially in the same transmission as the client's
>NEWKEYS.

Ugh.  So there are implementations that will send a NEWKEYS + 
SERVICE_REQUEST
+ USERAUTH all in one block without having any idea wheteher the crypto
handshake process has succeeded?

>But I don't see what this would achieve, since NEWKEYS is still 
>unencrypted.
>As-is, the server doesn't send an encrypted piece of information until it's
>replying to SERVICE_ACCEPT.

See above, I was using the SERVICE_REQUEST + SERVICE_ACCEPT to verify that
client and server are on the same page cryptographically.

>When re-adding "no-flow-control", I realized that the original definition 
>is
>deficient, and allows no room for implementations that support this
>extension, but still prefer not to use it.
>
>Ours would be an implementation like that. If this needs two 
>implementations
>to be added, I will implement it to make life easier for implementers of
>simpler SSH software, but I would prefer not to use it.
>
>I have therefore changed the definition as follows:
>
>  string  "no-flow-control"
>  string  choice of: "p" for preferred | "s" for supported
>
>To take effect, this extension MUST be:
>
>- Sent by both parties.
>- At least one party MUST have sent the value "p" (preferred).

That seems a bit wierd... the fact that a client or server is sending 
no-flow-
control already says "supported".  So you really just need at least one side
to set a boolean flag saying "yes, I really want this".  In other words no-
flow-control + boolean = false says the option is available, and boolean =
true says you must enable the option.

Peter.