Re: Terrapin

>> No, or at least not in theory; an attacker active enough to mount a
>> prefix truncation attack could easily enough edit it out of the kex
>> algorithm list.
> I don't think so, the kexinit packet is protected (included in the
> exchange hash), that's intended to protect against any manipulation
> of what's advertised in the kexinit?

Doh, of course.  I should make sure brain is operating before engaging
fingers!

> Looking over the RFC 4253, it should also be possibly to introduce a
> NEWKEYS2 without breaking backwards compatibility.  One should expect
> either a proper ack (however we define that), or a UNIMPLEMENTED
> response.

That...sounds plausible!

> But I'd imagine responding with UNIMPLEMENTED is a code path that's
> not well tested in implementations...

Personally, I consider that a feature.  I believe that rendering broken
implementations *obviously* broken is a Good Thing.

> In theory, one could maybe devise a way to send a NEWKEYS2 *instead*
> of NEWKEYS, with some new semantics.

Yessss...except that this form of NEWKEYS2 is not protected by the new
crypto, meaning we'd have to think hard about the impact of it getting
edited in flight by the attacker (eg, being replaced by NEWKEYS).

> On the other hand, I'd expect SERVICE_REQUEST/SERVICE_ACCEPT to be
> the first messages after NEWKEYS (except if there are IGNORE or DEBUG
> packets in between, deletion of which aren't that critical), so I
> don't get how an attacker deleting one of those wouldn't terminate
> the connection; I guess I have to read the paper.

I'd recommend it; it's not all that long (16 pages, of which two are
references and one is an appendix).  For this particular point, see
section 5 of the paper; it begins (manually patched up for email)

	While the fact that BPP does not implement a secure channel is
	troublesome enough, exploiting this vulnerability requires an
	analysis of the SSH protocol at the application layer.  As our
	attack achieves prefix truncation, it is only natural to ask
	which SSH messages can occur at the beginning of a secure
	channel.  Historically, the first messages exchanged are
	SERVICE_REQUEST and SERVICE_ACCEPT.  Removing either causes the
	connection to go stale, as the client will not begin the user
	authentication protocol.  Then our attack, while
	cryptographically successful, fails at the application layer.
	However, the SSH Extension Negotiation mechanism [9] introduces
([9] is RFC8308.)
	a new message, EXT_INFO, which can occur immediately after
	NEW_KEYS as the first message on the secure channel.  Some of
	the extensions that can be negotiated are security-relevant,
	providing a relevant attack surface for our prefix truncation
	attack and raising its impact.

>> Also, to really work fully right, SSH_NEWKEYS2 really should contain
>> something that requires knowing kex output, so it can't be a replay
>> at any level.
> It comes with mac that depends on the kex output, I think that should
> be enough?

If it's after NEWKEYS, as opposed to replacing NEWKEYS...hmmm.  I guess
so.  I'm slightly uneasy about it, and not just because "none" is a
possible MAC algorithm, but I can't quite identify any reason beyond
generic paranoia for that uneasiness.

>> To add protection to the A->B direction, A has to send the packet
>> and B has to check that it's (a) there and (b) the first post-kex
>> packet.
> The way I think of it, if the sender sends a specific packet
> immediately after NEWKEYS, and gets some kind of ack, then the sender
> knows that there's no "prefix truncation" on that direction.

Well, with vanishingly large probability, yes - but that caveat applies
to almost everything in the protocol.  (Though I suppose "vanishingly
large probability" is a bit of an abuse of language....)

> (Receiver doesn't get any certainty, but arguably receiver doesn't
> need any, since it's the sender that has an interest in getting their
> packets through).

Well, that depends on the details of the protocol.  The receiver may
well have an interest in traffic in the other direction getting
through (as opposed to being deleted by prefix truncation).

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