Re: Terrapin

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

Then IMO anything non-essential should be outright forbidden, on pain
of immediate disconnect by the peer.  Unfortunately DEBUG has
significant potential value, though at that point in the conversation
IGNORE is of little other use.

> Do you see a concrete problem, that makes it worth to change the
> protocol design on this point?

At the moment, only Terrapin.  But I have low-to-negative confidence
that there is nothing else lurking.

As you sketch, a direct attack based on pre-kex traffic can be mounted
either way (though it's less likely to succeed if non-essential traffic
is outright prohibited and thus more likely to be dropped before
causing trouble).  But something like Terrapin, which combines pre-kex
traffic which is not itself a problem with something else...I don't see
anything else offhand, but I didn't see prefix truncation either.

There are various defenses available, any one of which would stop
Terrapin.  I would prefer to implement all of them, or at least all
which can be done backward-compatibly, to provide something akin to
defense in depth, so that some variant nobody has yet published that
isn't stopped by one anti-Terrapin change may be stopped by another.
(As for the non-backward-compatible changes, I'm not sure there
actually are any; I think all the countermeasures I've seen suggested
can be done by using new kex algorithms specified with suitable
changes.  I'm fairly sure the two main fixes suggested in the Terrapin
paper's section 8, sequence number reset and full-transcript hash, can
be done as new kex algorithms.

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

That's what I would think.  But as a cryptographer I am strictly a
dilettante.

At least, if we do it as an alternative kex algorithm, it can be
replaced just as easily with some other scheme if it proves to have
some weakness.

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