> Looking at it from the other side, your typical IoT device will be sending, > for example, a 12-byte message every 15 minutes, meaning it'll take, if my > calculations are right, just under two million years to collect the 785GB of > data required to perform the attack.
I agree that it would be wise to evaluate each deployment scenario to decide which vulnerabilities have higher priority. But just a brief comment. If every message IoT device sends is a 16 bytes message consisting of one 8 byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we only need roughly 64GB in order to get a meaningful collision (50% chance of recovering the secret). The 768GB value we gave was for recovering cookies from realistic web browser traffic that could be triggered from JavaScript. It is true that in other TLS use cases (such as IoT) some attacks may no longer be relevant, but unless we are careful some HTTPS attacks may even be worse in these scenarios. Best regards, Karthik > > So you've got something where the devices aren't vulnerable to the problem > (and nor, in any practical case, is anything else), for which the devs > involved won't even know that any guidance on the situation exists, and for > which, if anyone really wants to attack them, they can use any of the dozens > of insecure-by-design holes that are present in the device to own the whole > thing, at which point what you do with your crypto becomes meaningless. > > So what you're proposing is essentially a non-solution to a non-problem... > still, if you feel like writing the memo for it, don't let me stand in your > way. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
