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

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

Hello Peter:


> > Does the draft need to be modified to make this explicit?
> It does need some explanatory text, I think.

OK. Draft submissions are currently off, but I have clarified this in my 
local version with the following text:

This message is sent immediately after SSH_MSG_NEWKEYS,
without delay. This allows a client to pipeline an
authentication request after its SSH_MSG_SERVICE_REQUEST,
even when this needs extension information.


> In that case it probably needs some security considerations
> text if it's sent before the successful completion of the
> crypto handshake has been confirmed. My guess is that putting
> the EXT_INFO inside the encrypted layer rather than in the
> client/server hello like SSL does is to protect it
> cryptographically, however sending EXT_INFO before you've
> got the other side's NEWKEYS means you could be sending it
> over a link where the crypto protection hasn't been successfully
> activated.

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

NEWKEYS is the last message in each direction that is still sent with the 
old keys (or in plaintext). Therefore, receiving NEWKEYS does not provide 
any sense of certainty that encryption is properly in place. Instead, the 
sense of certainy is provided by the key exchange. Either the key exchange 
is secure, and data encrypted using it is secure, regardless of whether the 
other side sends anything; or it isn't.

As-is, a client might obtain crypto parameters from a completed key 
exchange, and then:

1. Send NEWKEYS with the old crypto parameters (or in plaintext if this is 
the first key exchange).

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. If the client receives the server's NEWKEYS or not, it does not 
make a difference, because that's sent with the old crypto parameters (e.g. 
in plaintext).

This is not problematic for the client, because the client has already 
verified the identity of the server as part of the key exchange. If the key 
exchange is secure, anything the client sends will either be decrypted by 
the legitimate server, or it won't be decrypted.

Sending EXT_INFO is not problematic from the server's perspective either, 
because the server has not authenticated the client, and anything the server 
sends at this stage is world-readable. (Aside from IP blocking and similar, 
anyone can connect to the server, do their own key exchange, and get the 
info.)


> Yes, definitely, because I'd implemented it after
> both sending and receiving NEWKEYS, for the reason
> given above.

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.


> The issue isn't that it's wrong, but a question of
> consistency, the rest of the draft uses MAY and SHOULD,
> having an alternative synonym used in one location makes
> it more difficult to read.

OK, I have changed SHALL to MUST.


> I would put it back.  Having to do an entire RFC to
> document a single boolean flag seems like incredible overkill.

OK, I have added back definitions for "no-flow-control" and "elevation".

I have recently implemented "delay-compression" in our SSH Server and 
Client.

Our FlowSsh library implements "elevation", and it's pending implementation 
in our SSH Server and Client.

I have left out "accept-channels" completely. I have changed my mind about 
it having a compelling reason, and I haven't noticed interest in it.

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).

Since I cannot submit a new version right now, I attach a copy of my current 
local version.


denis


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

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

>There is no reason for a delay, but people do things for which there aren’t
>good reasons, and then others in the future have to compensate. This is to
>nip the problem in the bud.

I don't really see what the problem is though, it's like putting up a 
"Beware
of the dog" sign on a property with no dog.  The text appears to be warning 
me
about doing something that I'm not doing anyway, and that I have no idea how
to do.  Since the EXT_INFO has to follow the NEWKEYS, it blocks all other
messages so I couldn't delay it even if I wanted to without stalling the 
whole
handshake process.

>Does the draft need to be modified to make this explicit?

It does need some explanatory text, I think.

>EXT_INFO is sent by the party that sends it, immediately after that party 
>has
>sent its own NEWKEYS. Doing otherwise would contradict the “without delay”
>requirement.

In that case it probably needs some security considerations text if it's 
sent
before the successful completion of the crypto handshake has been confirmed.
My guess is that putting the EXT_INFO inside the encrypted layer rather than
in the client/server hello like SSL does is to protect it cryptographically,
however sending EXT_INFO before you've got the other side's NEWKEYS means 
you
could be sending it over a link where the crypto protection hasn't been
successfully activated.

>Does the draft need to be modified to clarify this?

Yes, definitely, because I'd implemented it after both sending and receiving
NEWKEYS, for the reason given above.

>One extension that needs this exact placement is “delay-compression”. For
>that to work, the client has a need to know whether compression should be
>started at the exact point it receives SSH_MSG_USERAUTH_SUCCESS. But the
>server may be reluctant to advertise its support for compression 
>beforehand.
>Sending the second EXT_INFO at this time is therefore ideal for both 
>parties.
>(If it was sent after SSH_MSG_USERAUTH_SUCCESS, there would be the exact 
>race
>condition that “delay-compression” is trying to solve.)

I think the draft should include some text like this as an explanatory note.
Getting EXT_INFO as a response to USERAUTH isn't a crash-and-burn thing, but
it just seems logically wrong to insert additional stuff in front of the
answer to the question you've asked.  So some explanatory text would be
useful.

>The word “shall” has a well-known meaning in English, and its use in this
>context is defined in RFC 2119. If this word was not meant to be used, I
>think RFC 2119 would not define it.

The issue isn't that it's wrong, but a question of consistency, the rest of
the draft uses MAY and SHOULD, having an alternative synonym used in one
location makes it more difficult to read.

>At this point, I can:
>
>- put it back in, just like it was; or
>- make it an independent submission.

I would put it back.  Having to do an entire RFC to document a single 
boolean
flag seems like incredible overkill.

Peter.

_______________________________________________
Curdle mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/curdle