Re: Terrapin

Mouse <[email protected]> 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?

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

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

I was first thinking: that wouldn't protect against an attacker deleting
packets prior to the key exchange. But on second thought, I don't think
that's a problem: For the initial keyexchange, the attacker can replace
any packet with an ignore packet, which effectively deletes it. And for
subsequent keyexchanges, we can rely on the NEWKEYS being the final
package protected using the old mac key. But it *is* a bit subtle, maybe
we need also consider the attacker inserting packets prior to key
exchange? For other reasons than the terrapin attack of deleting the
same number of packets after key exchange?

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.

Regards,
/Niels

--=20
Niels M=C3=B6ller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.