Re: Terrapin

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

>> But then, I don't like MSG_UNIMPLEMENTED to begin with; an
>> unrecognized message type byte, to me, indicates a severe bug in at
>> least one end. I consider tearing down the connection a much more
>> appropriate response in general.
> I think there are cases where a _recoverable_ notification of an
> unhandled packet would be useful.  You could imagine in principle a
> situation where one side says to itself: "I don't know whether this
> server is up-to-date enough to support SSH_MSG_NEWFANGLED, but I'll
> try sending it anyway, and if I get back MSG_UNIMPLEMENTED with that
> sequence number, it's ok, I have a fallback plan waiting".

True.  But in the presence of an existing mechanism to probe for the
presence of extensions, I would do that only after the extension is
known to be present.

> Of course this relies on the far end (a) continuing with the
> connection after sending UNIMPLEMENTED, completely ignoring the
> packet it didn't recognise, and not treating the UNIMPLEMENTED as a
> prelude to a disconnection; and (b) actually remembering to include
> the sequence number, so that 'my' side can reliably tell that the
> UNIMPLEMENTED referred to the packet it was thinking of.

Also depends on the far end (c) not treating it as "oh, I know that
packet type, it's SSH_MSG_EXPERIMENT47" and responding in a completely
unexpected way as a result.

> In my experience, servers (which send this at all) often forget (b).

!!

The brokennesses people implement never cease to amaze me.

> I think practically speaking UNIMPLEMENTED is not very useful.
> Partly for the reason I say here (people get the sequence number
> wrong); also because there are many cases it just can't report, such
> as a packet whose _type code_ is fine but some other detail is
> unsupported (like an algorithm id inside the packet);

Or like that one you mentioned, which didn't do rekeying at all.  It
obviously implemented KEXINIT packets but just didn't know how to
handle them at that point.

> and, thirdly, because the general strategy these days is to check in
> advance whether your peer supports a protocol extension _before_ you
> start sending its messages - seeking permission, rather than
> forgiveness.

That's my own tendency as well, at least in this case.

> (For example, in an ideal world we could have done EXT_INFO by just
> sending it unconditionally, relying on getting back a well-formed
> UNIMPLEMENTED to indicate that the other side didn't speak EXT_INFO,
> and then continuing without it if that happened.  But too many
> implementations get this totally wrong to make it a plausible
> approach.)

Yet another case where I'd prefer to render broken code _obviously_
broken.  Mollycoddling broken implementations just leads to
perpetuating brokenness.

In the EXT_INFO case, I really think the right thing would have been to
make it a global request.  Implementations that can't handle even
generating a proper REQUEST_FAILURE should have been told "fix your
code, see RFC xxxx section a.b.c" rather than "oh, poor you can't
handle actually implementing the spec, don't bother your pretty little
head, we'll work around your incompetence".

The only benefit I see to doing it as flag algorithm names is to work
around the misfeature of kex signing over only some of the initial
messages.

/~\ 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