Re: Terrapin

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

>> My second thought: always make the first message after kex a
>> verifier message, with content depending predictably on kex output,
>> as a final test of the integrity of the encrypted channel.
> Say, like sending a SSH_NEWKEYS2 message?  So key exchange ends by
> sending SSH_NEWKEYS using old keys (i.e., cleartext for the initial
> key exchange), followed by an SSH_NEWKEYS2 message using the new
> keys, where the purpose of SSH_NEWKEYS2 is to (implicitly) agree on
> the initial sequence number.

I don't much care what it's called; SSH_NEWKEYS2 seems like as good a
name as any.  The point of doing it is that prefix truncation would
delete it from the packet stream and thereby alert the receiver to the
probable attack-in-progress.

Except, of course, that the receiver can't take it that way unless the
sender is known to always send it.  I haven't come up with a good way
to ensure that without a protocol change.  The closest I have come up
with is for each end to send an extension request as its first post-kex
packet and expect a response of *some* kind to it before doing anything
further.  But even that is difficult to handle when talking to a peer
that doesn't implement such measures, since it could send a more or
less arbitrary number of packets before sending the response to the
extension request.  (I've also run into servers which crash when faced
with an extension request they don't understand, though admittedly I
have little sympathy for any implementation that gets the protocol that
far wrong.)

> I haven't read the paper yet, I've only had a quick look at the intro
> material.  I got the impression that new "modern" mac algorithms that
> apply mac to the ciphertext, are more vulnerable than the old
> fashioned way of the original rfc 4253,

Yes.  They send packet lengths in the clear, so the attacker doesn't
need to guess at anything to perform prefix truncation.

> If one were to make larger changes, one could also consider stuff
> like deriving the new keys based on hashing of the newly negotiated
> shared secret *and* the sequence number of the SSH_NEWKEYS message.

A simpler and more reliable way to defeat prefix truncation would be to
reset the sequence numbers upon completing kex.  Reset it to a "random"
number dependent on kex output and prefix truncation success rates will
take a severe nosedive.

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