Hi, Is it possible for the standards/RFCs to dictate de-prioritization of certain troublesome TLS processing patterns?
The RFCs -- may suggest identification of such patterns, -- may suggest implementation of certain low priority processing queues/threads/executions. Following is an example troublesome pattern which may or may not be coming from attackers: Please consider a scenario wherein a server is allowing the clients to upload big files. The client is mostly doing the transmission in this case. The client can have a rogue TLS implementation with the following intentional changes: 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing power requirements) and non paralleliz'able cipher suite. 1. After the handshake, always send all the TLS records (Application Data) plain text fragment size which is no greater than 1 Byte. 2. Always send a padding of max possible or big size (eg 256 Bytes) So the TLS record will look like: (1.2 version) 5 B Hdr + 16 B IV + 1B Cipher Text + 32 B HMAC + 255 B Padding.= 309 Bytes including the tls header. Additionally the client's network stack can have some changes which may possibly cause the following too: A. TCP segmentation B. IP Fragmentation Now the server will have to i. do ip reassmebly/ TCP reassembly to recover every single TLS record ii. The TLS record thus recovered will undergo decryption/HMAC verification only to obtain 1 Byte of plaintext application payload. If many such rogue clients sending huge files to the server, the server will end up denying services to the genuine clients. Now A and B above are not related to TLS, but the other points do have something to do with the implementations. If the server's TLS implantation can recognize this pattern [possibly from an attacker], it can give low priority to such requests so that other genuine requests may get served without being affected. If such preventive measures are a part of the RFCs, the implementations will be less vulnerable. Thanks Jitendra _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
