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

[Peter Gutmann <[e-mail]>]

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.