Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:
> 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.
I'd be happy with a version 2.1 for that (and with other backwards
compatible counter measures until that is deployed). But perhaps one can
use the same hack as for extensions (rfc8308), to add a magic indicator
to the kex_algorithms_list?
> 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.
Yoy shouldn't need an extension, a nop global request would do? It will
cost a roundtrip if you wait for the response. If I understand this
right, each party will only be able to add this protection to one of the
directions, right?
I don't think there needs to be any request. Consider an extension which neither adds new messages nor changes the form of any existing message. Instead, any time both parties have advertised the extension in the kex_algorithns list, the semantics of NEWKEYS are changed such that the sequence numbers are reset in a defined way.
-- Jeff