Re: Terrapin

[Simon Tatham <anakin%pobox.com@localhost>]

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:
> 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".

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.

In my experience, servers (which send this at all) often forget (b). In
the few cases I've seen of PuTTY receiving an UNIMPLEMENTED in the wild,
it has often had a sequence number field of zero, which was clearly not
actually referring to packet #0 of the session.

But I think you're also right that it's often an indicator of bugs. Two
cases I've seen were a server that simply couldn't cope with rekeys at
all, and sent UNIMPLEMENTED in response to the KEXINIT that attempted to
start a rekey; and one sending it during initial KEX because it had got
confused about whether it was doing DH group exchange or fixed-group DH,
with their slightly different message sequences.

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

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

Cheers,
Simon
-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, "<anakin%pobox.com@localhost>"))

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <anakin%pobox.com@localhost>