Terrapin Mitigation: "strict-kex"

[ecki]

Description

Hello,

is Mina or any contributor planning to work on adding the new OpenSSH protocol extension "strict-KEX" for mitigating Terrapin attacks?

Also did somebody check for the counter overflow conditions mentioned in the advanced counter manupulation section of the paper?

BTW: when implementing config options, I would do it like jssh which allows to define a "required" mode, so you can set up a listener which rejects any handshakes without this protection. (if you want to make "supported" configurable I dont care, seems to be not a big compat problem if implemented correctly)

In addition to resetting the counters the strict mode probbaly also should reject the "filler" debug and ignore mesages - I hope PMC received detailed guidance from the Terrapin team?

Motivation

Users want to mitigate the new protocol attac which can only work if client and server are extended.

Alternatives considered

Turning off the ciphers is an interop problem.

Additional context

https://terrapin-attack.com

[lgoldstein]

According to OpenSSH PROTOCOL - section 1.9 transport: strict key exchange extension

Ater sending or receiving a SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero

However, it does not specify which sequence number to reset - the incoming our outgoing. Bear in mind that the NEWKEYS message is "symmetrical" - if we sent one, then an incoming one is due any time and vice versa. Since the sequence number is part of the encryption (if this is not the 1st NEWKEYS) then we need to know whether we sent the request or are responding to it.

[lgoldstein]

Working on it (trying to at least...)

[TrueSkrillor]

According to OpenSSH PROTOCOL - section 1.9 transport: strict key exchange extension

Ater sending or receiving a SSH2_MSG_NEWKEYS message, reset the packet sequence number to zero

However, it does not specify which sequence number to reset - the incoming our outgoing. Bear in mind that the NEWKEYS message is "symmetrical" - if we sent one, then an incoming one is due any time and vice versa. Since the sequence number is part of the encryption (if this is not the 1st NEWKEYS) then we need to know whether we sent the request or are responding to it.

Strict key exchange resets the sequence number of the corresponding direction after it has received a SSH_MSG_NEWKEYS message. I. e. when receiving SSH_MSG_NEWKEYS from the remote peer reset the incoming sequence number, when sending SSH_MSG_NEWKEYS reset the outgoing sequence number. The SSH_MSG_NEWKEYS itself is handled under the old sequence numbers (sequence number 0 will be the first message after SSH_MSG_NEWKEYS).