To further Andrew's point: I think if we are going to publish this RFC then we should immediately also publish the following RFCs: ----------------------------------------
*SHA-256 Truncated to 32 bits (SHA-256/32)* This RFC has value because ultra-low-bandwidth mesh networks cannot afford a 32-byte overhead per packet for a full SHA-256 hash. Since developers in these environments are already truncating hashes to fit into 4-byte fields to save bandwidth, we need to specify exactly which 32 bits of the SHA-256 output to keep, ensuring that when attackers forge their packets, the collisions happen in a standardized, interoperable way. We should publish this anyway despite a 32-bit hash having a completely broken collision space where an attacker could generate a malicious payload with a matching hash almost instantaneously, defeating the entire purpose of data integrity or signature verification. *AES in Electronic Codebook (AES-ECB) Mode * This RFC has value because developers writing high-throughput, low-latency firmware often complain about the CPU overhead of managing Initialization Vectors (IVs) and block chaining in GCM or CBC modes. Since they are already hardcoding zeroed-out IVs or ripping out the chaining logic to save cycles, an Informational RFC on AES-ECB would ensure their insecure implementations can at least decrypt each other's traffic. We should publish this anyway despite ECB mode encrypting identical plaintext blocks into identical ciphertext blocks, leaking structural data, offering no diffusion, and being widely considered broken for almost all practical applications. *RSA with 512-bit Keys (RSA-512)* *(perhaps this one is familiar already to some.....)* This RFC has value because certain cheap, ultra-constrained IoT devices lack the computational power or memory to process an RSA-2048 handshake before the connection times out. Vendors are going to use 512-bit keys anyway just to get the devices on the network. Therefore, we must formally document the exact padding schemes for RSA-512 so that these easily compromised smart home devices are perfectly interoperable across different vendor ecosystems. We should publish this anyway despite the fact that RSA-512 can be factored by modern consumer hardware in a matter of hours, making it trivial to break. Oh....wait....we already published this one long ago and it led directly to FREAK 16 years later. ---------------------------------------- I hope this *reductio ad absurdum* argument is obvious to everyone with regards to why it's unwise and misguided to publish weaker RFCs when we have demonstrably stronger algorithms with low-to-no cost difference that serve the same function.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
