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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

> Why add fixed-function fields to a generic extension mechanism?

So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCEPT.

These two messages always negotiate the service (e.g. "ssh-userauth"). So EXT_INFO, which is a replacement, also always negotiates the service.

This is in fact simpler than adding a "services" extension, and then mandating that this extension "MUST" be handled by all implementations. If some functionality must always be handled, a fixed field is appropriate.


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

Okay, imagine this:

(1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + ACCEPT.

(2) The KEXINIT extension instead signals that extension fields can be added to SERVICE_REQUEST + ACCEPT.

(3) Presence of the KEXINIT extension further signals that the server can send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST.

Do you see that this results in the same proposal, just with renamed messages?

Damien Miller <djm%mindrot.org@localhost> , 12/3/2015 6:31 AM:

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