On Tue, Oct 13, 2020 at 06:41:50AM +0200, Achim Kraus wrote: > Hi Ben, > > > > >> Just as forecast: > >> Without agreement, that the CIDs must be encoded using deterministic > >> interpretation, which in my opinion obsoletes these "number games", > >> next Summer either Raccoon or Kenny will write up their next > >> "time side channel attack" on this. > >> (The ambiguity will end up in try out the MAC for both "different > >> MAC_write_key" and so create a time signal. Or with "same MAC_write_key" > >> the receiver will not know by the failing MAC, which interpretation is > >> the right. I guess, this will end up in decrypt twice, also obvious time > >> signal.) > > > > Just to check my understanding: your forecast of an attack is predicated on > > implementations that accept both potential MAC calculations proposed (CID > > length before CID and CID length after CID)? I do not think we should > > allow things to progress to a state where accepting both forms is > > encouraged, precisely because it leads to this sort of difficulty. Hence, > > my suggestion to assign a different extension codepoint, so an > > implementation knows exactly which procedure to use. > > > > My concerns are based on permit ambiguous CIDs.
Ah, I think I understand better now (based on this and the rest of your note). I do not think we should allow such ambiguous CIDs, since (as you note) they would require some "trial decryption" processing and the ensuing time channels. That said... > > Attempting to construct a trivial example on the fly, (hex) > > > 01 01 02 02 01 <513 bytes of plaintext content> > > > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202, > > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be > > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201, > > DTLSInnerPlaintext.content = <513 bytes>. > > That results in my opinion in cid 01 and cid 01 01 being valid for the > same peer and same time. The attack does not require that both are valid for the same peer at the same time -- the attack can still occur when the party producing the MAC is induced to use the "wrong" (invalid CID) interpretation of the byte stream but then the version with valid CID is presented to the party verifying the MAC. If the internal structure (including length encoding) of the CID is opaque to the party producing the MAC, that party cannot validate the data used as input to the MAC. (Sorry for duplicating this previous paragraph here and on the github issue.) -Ben _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
