Antoine and I were discussing draft-ietf-tls-certificate-compression over lunch today and we think there could be a potential attack on the current scheme which could be fixed with some changes.
Currently the CompressedCertificate is included in the handshake transcript.. However let's say a server fragments it's compressed certificate message into multiple records, and an attacker has found a vulnerability in the decompression function based on the timing in which the data is delivered to the decompression function due to a race condition. They could manipulate the CompressedCertificate message to manipulate the peer to decompress something other than what the sender sent even though the handshake transcript remains the same. Normally this wouldn't matter if there were only certificates, however we have extensions in certificates which could manipulate how certificates can be interpreted. This creates a time to check to time to use bug which relies on the security of the decompression function to determine the security of the TLS exchange. This is definitely a far fetched attack I don't think this is desirable to base the security of TLS on the security of a decompression function. This is probably solvable by hashing in the uncompressed cert message into the TLS transcript rather than the compressed message which seems more secure because it enforces that the client and server have the same state of the uncompressed message. Subodh
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
