Re: Terrapin
Mouse <[email protected]> Thu, 28 Dec 2023 10:08:30 -0500 (EST)
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <[email protected]> |
>> If the sequence number is not usable for its intended use, then, >> unless someone has a use it _is_ usable for, it should be fixed or >> eliminated. > The sequence number is also used in MSG_UNIMPLEMENTED to refer to the > unimplemented packet. Fair point. The question then becomes a tradeoff: is this use of the sequence number as currently defined useful enough to make it worth keeping? I'm not sure what I think of that. 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. That's what my implementation does. (If-and-when peers start throwing such atrocities at me, I'll have to figure out whether to add a misfeature-compatibility workaround or write off interoperability with them.) And I _really_ don't like the use of unrecognized packet type bytes, depending on them to produce UNIMPLEMENTED responses, as a Terrapin workaround. Besides a general dislike for abusing a misfeature, the result is incompatible with anyone who's using currently-unused packet type fields for any other purpose. Sooner or later something will get defined to use one of them, at which point this Terrapin workaround will explode badly - or, worse, the presence of the workaround in the SSH ecosystem will make it effectively impossible to introduce any such new feature, forever crippling SSH extensibility by effectively rendering all currently-undefined type byte values permanently undefined. > [T]heir approach imply adding an other magic symbol in the kex > algorithms list, that's why I prefer to add new algorithms. The > intent of the specification is not to have some magic algorithm names > that must never appears in the other direction. I agree. > I know that we already did it with extinfo for good reasons, to work > around broken implementations that would otherwise disconnect, if I > remember well. I don't consider that a good reason. I firmly believe any implementation so broken as to disconnect upon its peer trying to use the defined extension mechanisms should be rendered _obviously_ broken, so as to get it fixed or replaced. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B