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

[Peter Gutmann <[e-mail]>]

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.