Re: Terrapin

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

> On the merits of the UNIMPLEMENTED mechanism itself.  My view:

> Pro: It looks like a reasonble and simple way to enable gradual
>      improvements of the low-level transport protocol, without
>      bumping the version number.

To a point, yes.

> Cons: I'm not aware of any actual usage during the last few decades
>       of ssh.

True.  But is that a failing of the mechanism, or is it a virtue of the
original design?

>       It could have been used for MSG_EXT_INFO, but for reasons I'm
>       don't remember (or maybe never was familiar with), RFC 8308
>       defines magic symbols for the key exchange methods list
>       instead.

I don't recall the reasoning, if indeed I ever saw it.  My best guess
at the moment is that that was done so that its the presence or absence
would be signed over by kex - that is, it's a workaround for kex
signing over only some of the cleartext packets, rather than all of
them.  More on this below.

> Cons: If one implementation wants to unilaterally deploy an
>       extension, this mechanism doesn't help much, since message
>       numbers require "standards action" registeration with iana, and
>       that's a small space.  The "reserved" and "local" message
>       numbers are fine for experiments and development, but *not* for
>       features to be deployed across the Internet.

Very true.

As for kex signing over only some of the cleartext, it's been so long I
don't recall any discussion that might have taken place on that.  But
it does occur to me that there is some difficulty defining the range of
bytes to be signed over.  If one party can send packets not strictly
necessary for kex, the other party must guess where the "end of
cleartext" point is.

I would say the best way to handle this would be to have a packet which
is sent by each party when it has sent everything it's going to before
NEWKEYS.  The kex hash then hashes everything before - or perhaps
before-and-including - this packet.  Any traffic whatever sent after it
and before NEWKEYS is specified to cause immediate disconnection.

Given the current definition of UNIMPLEMENTED, this could in theory
even be deployed unilaterally, though it would break interop with
implementations that have taken my and pgut001@'s stance to heart and
disconnect instead of sending anything back.  Such behaviour _is_
contrary to the spec as it stands, which makes such an evolution of the
protocol reasonable (or, at the very least, defensible).

While reading 4253 while writing this message, I was somewhat surprised
to discover that the specification that the kex hash hashes over only
fragments of the cleartext traffic is not part of SSH, but rather part
of the kex algorithm.  This means that we could simply define new kex
algorithms which (a) send an "end of cleartext" packet once they've
sent everything they want to, (b) hash over all cleartext from the
beginning of the connection to the beginning (or end?) of the "end of
cleartext" packet, and (c) specify that any traffic whatsoever received
after "end of cleartext" and before NEWKEYS MUST cause an immediate
disconnect.

This does open up a possible DoS, in that it means the implementation
must buffer all cleartext in both directions, so injecting an
unreasonable flood of IGNOREs can run the implementation out of RAM.
This could be as simple as adding a note that an unreasonably long
cleartext conversation, as well as excessively large single packets, is
grounds for disconnecting.

The hash could be defined to hash over not the cleartext conversations
but instead over hashes of them, meaning that an implementation doesn't
need to buffer all the text, instead just keeping two
hashes-in-progress and feeding the cleartext into them.  But I'm not
sure whether that would be cryptographically suitable.

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