Re: Terrapin

Mouse wrote:

> > There is this packet sequence number that is provided by the
> > protocol.  The authors of the paper show that the way this sequence
> > number is computed is not appropriate for use by some algorithms.
> 
> I'd say, instead, "is not appropriate for its intended use".

You are right. We could even say "is not appropriate for one of its
intended use".

> I would actually prefer a protocol revision, though, to _fix_ the
> issues instead of just working around them.  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. This usage of the specified sequence number seems
still valid and a monotonically increasing counter is appropriate to
uniquely identify packets in the stream. So maybe we have to keep it
unchanged for that purpose.

> > [...].  Yet this is actually debatable because their approach is only
> > useful when the client and the server both implement the
> > countermeasure.
> 
> So is yours, to be fair.

Yes it is. But their 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 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'am just not comfortable with having yet another pair of such magical
symbols that globally change the behavior of some existing
algorithms. IMHO This somewhat breaks the modular design of
SSH2. But maybe that's just me.

-- 
Alexandre