Re: Terrapin

Mouse <[email protected]> writes:

> I don't recall the reasoning, if indeed I ever saw it.  My best guess
> at the moment is that that was done so that its the presence or absence
> would be signed over by kex - that is, it's a workaround for kex
> signing over only some of the cleartext packets, rather than all of
> them.  More on this below.

I don't quite follow. Assuming that MSG_EXT_INFO is sent after completed
keyechange (like just before or just after SERVICE_REQUEST), and
assuming that there's some protection against packet deletion attacks.
Then only reason it needs protection in kex is the design choice to
advertise support up-front during the otherwise unprotected handshake.
Instead of sending it oppurtunistically in the encrypted session and
depend on the UNIMPLEMENTED mechanism if the peer doesn't support it.

> As for kex signing over only some of the cleartext, it's been so long I
> don't recall any discussion that might have taken place on that.

I don't have all the details paged in, but I think the basic counter
argument is: you shouldn't add anything to the unencrypted handshake
which isn't *essential* for the handshake, and the essential things
*are* hashed. A corollary is that if you enable bug-compatibility
workarounds depending on the other sides behavior, you should do that
based *only* on data that is included in the hash, most relevant being
the kex message and the version string.

As I remember (without actually checking), this is more or less
unchanged since the very first -00 drafts, and the wg deemed it to be
good enough at the time.

Do you see a concrete problem, that makes it worth to change the
protocol design on this point? E.g., say an attacker can send DEBUG
messages in the handshake (either because the attacker has a middle-man
position, or because the attacker controls the peer) that somehow makes
the receiving implementation behave badly. Maybe it sends the debug
messages to a logging framework with exploitable bugs. Does it matter if
we add some authentication that can detect the particular case of the
evil packet originating as part of a mitm attack, and disconnect?
Probably not, damage is already done. And the attacker could mount more
or less the same attack directly, without posing as a middle-man.

> The hash could be defined to hash over not the cleartext conversations
> but instead over hashes of them, meaning that an implementation doesn't
> need to buffer all the text, instead just keeping two
> hashes-in-progress and feeding the cleartext into them.  But I'm not
> sure whether that would be cryptographically suitable.

At least, there's *usually* no cryptographic problem in adding one more
level of hashing.

Regards,
/Niels

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