Re: Terrapin

Alexandre Becoulet <[email protected]> writes:

> A way to fix this without breaking and bloating the protocol would be
> to introduce variants of the problematic MAC and AEAD cipher
> algorithms that would use their own sequence number, as already done
> in AES-GCM. For instance, we could have "hmac-sha2-256-seq0" and
> "chacha20-poly1305-seq0" algorithms that use a separate sequence
> number that is set to zero when the algorithm is initialized.

If that works, dealing with in in key-exchange seems like a good
approach. Either per-algorithm as you suggest, or some magic symbol
added to the kex-algorithm list.

One subtlety if resetting sequence number to zero is that it risks
breaking MSG_UNIMPLEMENTED (since seqno may get ambiguous in some cases,
e.g., if for some reason there are multiple keyexchanges only few
packets apart). So please keep this in mind. Maybe reset seqno only at
the initial key exchange? Maybe there's some value in somehow ensuring
agreement on the sequence numbers of the initial NEWKEYS messages?

I see some value in the original seqno that is continuously incremented
through out the connection, in that it makes it a little easier to think
about correct packet order attacks regardless of the key exchange
boundaries. And as I understand it, the problem is if an attacker can
get the parties to have different views on the correct sequence number
of the NEWKEYS packet for the initial key exchange; for key re-exchange,
it doesn't matter.

Regards,
/Niels

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