Re: Terrapin

>> 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?

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.

>> 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?

Hmm.

I'd have to think more.  I think a NOP global request should be as good
as an extension request - but is there such a thing, or would that
require a protocol revision?  I can't find one in a few moments
searching 425[0-6], and an extension request with want-reply true
amounts to much the same thing.

I'm not sure either one works right, though.  If the attacker injects
the relevant request in the clear just before NEWKEYS, could the
response legitimately be sent after the other end's NEWKEYS?  I forget
whether responses can be delayed across NEWKEYS.  (After seeing what
Terrapin says about AsyncSSH, though, I have little faith that every
implementer would get it right....)

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 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?

Sort of.  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.

>> Yes.  They send packet lengths in the clear, so the attacker doesn't
>> need to guess at anything to perform prefix truncation.
> Ah.  I consider that bad (and I wasn't aware, since I've not
> implemented any of those variants, not even gcm).

I don't think GCM does that.  Based on the Terrapin paper, GCM is
immune because it does its own internal serial numbers, which makes it
semantically equivalent to resetting the serial numbers at NEWKEYS.

> I know it's really difficult to hide from an attacker doing traffic
> analysis, but with hidden lengths fields its at least possible to
> play with counter measures based on IGNORE packets that lets us
> decorrelate TCP packet boundaries and ssh packet boundaries (my
> implementation isn't that sophisticated, but it aims to put tcp
> boundaries inside the body of some IGNORE packet, and limit possible
> tcp packet sizes to a small set).

Yes, moussh isn't that smart yet either, but I have long wanted to put
socket write() boundaries - which often end up turning into TCP segment
boundaries - inside IGNORE packetrs.

>> 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.

On thinking more, I'm not sure this actually provides any more
protection than resetting to zero.  I was thinking that the sequence
number should be unpredictable to the attacker, but I'm not sure it
really affects anything more than using the sequence number as a crib
for attacking the bulk crypto.

> I was first thinking: that wouldn't protect against an attacker
> deleting packets prior to the key exchange.

No, it wouldn't.  It _does_, however, completely break prefix
truncation; it's no longer possible to make the first post-kex packet
disappear without being noticed, even by manipulating the pre-kex data
stream.

It would introduce a new attack, a downgrade attack based on making
pre-first-kex EXT_INFO negotation disappear would be introduced,
because there would then be nothing to ensure that the missing packet
got noticed.

But then, as you point out, "deleting" it by replacing with with IGNORE
works even better.  To defeat that, you really want first kex to sign
over the entire pre-kex data stream, not just the fragments it is
currently specified to sign over.  But then we have to find or create
some way to clearly mark the "here is where the signed-over portion
ends" in the pre-first-kex datastream.

> If it's the case that detection of packet insertion and deletion
> prior to keyexchange doesn't matter in itself, so we don't need
> continuity of the sequence number, would it work to simply reset the
> sequence number to zero when taking new keys into use?  Then both
> ends could surely agree on it.

Yes, that's one of the suggestions the Terrapin paper gives as a
countermeasure.  It would completely defeat prefix truncation.

And, as you point out, continuity of sequence number doesn't defeat
attacks based on deleting pre-first-kex packets, because they can be
replaced by IGNORE packets.  It would help with attacks that are based
on inserting packets immediately before NEWKEYS, if there are any; I'm
not aware of any, but I haven't thought about it for more than seconds.

If NEWKEYS2 includes its sender's idea of the NEWKEYS packets' sequence
numbers, I think that would defeat all the sequence-number attacks.
I'm not sure whether it would open up any others; the only one that
comes to mind is that it would include some attacker-known data in an
encrypted packet and thus could serve as an attack crib.  But then, the
packet type would be that as well.

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