Re: Can an SSH_MSG_EXT_INFO have zero entries?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Someone has just reported an SSH implementation that sends
> SSH_MSG_EXT_INFO with zero extensions present, i.e.:

>     byte       SSH_MSG_EXT_INFO (value 7)
>     uint32     0

> The RFC says:

>    Implementations MUST accept well-formed SSH_MSG_EXT_INFO messages
>    up to the maximum packet length they accept.

> but never defines what a well-formed SSH_MSG_EXT_INFO message
> actually is.

I would assume it's one that conforms to the syntax given.  8308
describes it as

     byte       SSH_MSG_EXT_INFO (value 7)
     uint32     nr-extensions
     repeat the following 2 fields "nr-extensions" times:
       string   extension-name
       string   extension-value (binary)

which looks to me as though that is a perfectly good SSH_MSG_EXT_INFO
message, just one that happens to have a zero nr-extensions.

> In my case I've defined one with zero entries as not well-formed,
> since it's a message used to communicate extensions that communicates
> no actual extensions.  Should a message like this be accepted?

Well, an implementation is free to refuse to communicate for any reason
it pleases.  But I would say that, in as far as conformance to the spec
goes, that's a perfectly good SSH_MSG_EXT_INFO.  Supporting no
extensions on a particular connection strikes me as a perfectly
reasonable thing to do, just as (for example) the empty file is a valid
text file.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B