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.
> 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.
or
> - Application record on CID 63 containing 04 00 02 FF, or
> - Application record on CID 63 01 00 05 containing FF.
being valid for the same peer and same time.
That seems to be the precondition for the threats. Permitting such
ambiguous CIDs may be then the root cause for such a "time side channel".
With the reference from Antoine (https://eprint.iacr.org/2020/114.pdf,
Section III.D), I started to consider the encoding of a "variable length
CID" to be the real spot. That points for me to the same direction, it's
that encoding not the position of the cid-lenght.
best regards
Achim Kraus
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
