On Sun, Oct 11, 2020 at 08:26:47AM +0200, Achim Kraus wrote: > Hi Joe, > > > [Joe] It's unfortunate to find issues that require breaking change at > > the end of the review cycle, especially for a draft that has taken a > > long path to get here. If there is an issue that is exploitable, even > > in a corner case, someone will develop an attack, clever name, logo and > > website and we will all have to scramble to deploy a fix. It's better > > to fix now rather than later. > > Agreed, therefore I wrote at the begin of the discussion with Ben: > > >> I would prefer, if this is not changed again without strong > >> arguments! > > > In this case, I don't have a way to > > exploit this issue, but unless someone has a way to demonstrate that > > this is not going to be an issue then I believe it is prudent to fix it > > now. > > > > In my opinion, ONE change may be possible. A server may be configured to > use only the old, only the new, or both by "try on the client's finish". > I'm not happy with such "dirty" work-around. I would prefer to do so for > something more the "cryptographic hygiene". > > So, if the MAC is considered to be adpated again, should it not be > discussed, why at all the cid-length should be put in? > I asked this already in January 2019 > > https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915 > > The MAC contains already a overall length. Even in that discussion, no > one mentioned the reason for adding it. So if there a doubts about > injection, why not remove it at all?
The problem is the follows: Take the following input to the MAC (MtE case): <seqnum> 19 FE FD 63 01 00 05 04 00 02 FF 17 There is no way to tell from that input if it is: - Application record on CID 63 containing 04 00 02 FF, or - Application record on CID 63 01 00 05 containing FF. The overall MAC length will not catch this, because the overall length is the same in both cases. And even if it seems that the data lengths after depad should be different, it is unsafe to rely on depad length. Stripping the CID length will not solve the issue. Heck, if cid length is removed, the very above example is still ambiguous, now for: - Application record on CID 63 01 containing 04 00 02 FF, or - Application record on CID 63 01 00 05 containing FF. For EtM construction, it is even worse. There is no way to check for consistency, because CBC mode leaves end of message intact even if IV or length are bogus, meaning all the depad and content-type checks will pass. The AEAD construction is not affected. Even if the design is pretty bad, the CID is the only variable-length field in AD, so its length can be inferred from AD length. Swapping order of CID and its length will solve it: <seqnum> 19 FE FD 01 63 00 05 04 00 02 FF 17 - Application record on CID 63 containing 04 00 02 FF. <seqnum> 19 FE FD 04 63 01 00 05 00 02 FF 17 - Application record on CID 63 01 00 05 containing FF. Tricks altering CID length are not possible, because those will alter a byte at fixed position. And one can not alter CID without changing its length either, as those will alter bytes at fixed position as well. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
