Re: Feedback on draft-ssh-ext-info-00

On Thu, 3 Dec 2015, denis bider wrote:

> I have posted a new draft to address this:
> 
> https://tools.ietf.org/html/draft-ssh-ext-info-03
> 
> The difference is that there is now a "services" field in EXT_INFO:
> 
>     byte       SSH_MSG_EXT_INFO (value 7)
>     name-list  services
>     uint32     nr-extensions
>     repeat "nr-extensions" times:
>       string   extension-name
>       string   extension-value
> 
> And a section to describe it:
> 
> 3.5.  Service Negotiation
>   The client and server each include a name-list of supported services
>   in EXT_INFO. The name-lists are matched to negotiate a service in the
>   same way as name-lists are matched in KEXINIT. Clients and servers
>   that support only "ssh-userauth" MUST send this service name only.
>   Implementations supporting only one service MAY assume it will be
>   negotiated, and MAY send messages on that premise without waiting.
> 
> Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST +
> ACCEPT?

This is over-complicated. Why add fixed-function fields to a generic
extension mechanism?

I'd support a simple magic name, offered in KEXINIT to indicate that an
implementation is prepared to accept a SSH_MSG_EXT_INFO packet.
Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't
have other further effects on the protocol. To do otherwise is IMO quite
surprising.

Then, if you want to define a "die-service-request-die" extension that
changes the protocol flow then you can do that without requiring other
implementations to follow suit.

-d