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

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

> I'm suggesting you specify what is sent, not how
> implementations test for it. 

It is important to specify what to test for. Just weeks ago, we had a conversation about how RFC 4253 should have spelled out that the "reserved" field must be sent as zero, but must not be checked that it is zero.

It is important to specify what things implementations should not check for, when incorrect implementation may cause compatibility issues.


> The benefit is that ~ a paragraph of fairly
> useless verbiage in your spec disappears.

You are losing my respect as we continue.

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

On Thu, 3 Dec 2015, denis bider wrote:

> > If there's a functioning extension mechanism,
> > then why would there be competition?
>
> To extend other aspects of SSH that EXT_INFO cannot. This could be to change
> some aspect of algorithm negotiation, for example.
>
> For instance, there has been a problem in how AEAD is negotiated. Besides
> what OpenSSH did - implementing a private algorithm for AES-GCM - another
> possible solution could be an extension where both client and server put
> something in their key exchange algorithms field. If both client and server
> do this, then the result of MAC negotiation is ignored if an AEAD encryption
> algorithm is negotiated.
>
> But why do you even feel the need to call this out? Is it any harder to
> call:
>
>     is_in_namelist(name, namelist)
>
> instead of:
>
>     is_at_end_of_namelist(name, namelist)

I'm suggesting you specify what is sent, not how implementations test
for it. The benefit is that ~ a paragraph of fairly useless verbiage
in your spec disappears.

> > IIRC I've heard of at least one server that doesn't
> > implement ssh-userauth.
>
> This is possible with EXT_INFO also. Send an extension name and value
> informing the client of what you implement. No need to waste a round-trip
> for 99.999% of other users.

I'll repeat my opinion: an extension mechanism is not the place to
fundamentally retcon parts of the protocol. It breaks orthagonality
and turns implementations into spaghetti.

Perhaps you want a "no-service-requests" extension instead?

-d