Former and latter is a horrible way to refer to attacks :) what I really meant is that when a receiver processing of timing of same TLS record chunks triggers a bug in the decompressor.
Subodh ________________________________ From: TLS <tls-boun...@ietf.org> on behalf of Subodh Iyengar <sub...@fb.com> Sent: Thursday, March 22, 2018 10:11:33 AM To: David Benjamin Cc: tls@ietf.org Subject: [Potential Spoof] Re: [TLS] potential attack on TLS cert compression Ya I think you have the right idea. The former attack is the one that I'm more concerned about, i.e. compression libraries almost always provide streaming interfaces. Another case is that TLS implementations which are the users of some decompression api might also provide the frames to the decompression library in non-deterministic order. With draft-25 we've authenticated the record header so the attacker can't force the data to be processed in a different chunking than the server which is why I mentioned that the only leverage the attacker has is timing. We missed the draft-23 bus on pointing out the attack 😊 Compression libraries can get complicated especially ones that use multiple cores do speed up decompression. It's not necessary that the library does ASN.1 streaming, but you can imagine an implementation where a lower layer could stream the compressed cert message into a uncompressed buffer, and then send the uncompressed buffer to an ASN.1 parser. The attack assumed malleability in the former process because records are already streaming so the data can be parsed in a streaming way. I admit this depends on the implementation and various other magic factors, however it seems unfortunate to base the security of TLS on the security of the decompression function and the way that an implementation might use the decompression function, when there seems to be a simple? way to solve it. Subodh ________________________________ From: David Benjamin <david...@chromium.org> Sent: Thursday, March 22, 2018 9:58:57 AM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] potential attack on TLS cert compression To make sure I understand the issue, the concern is that your decompression function provides a chunk-by-chunk interface, there's a bug and the division into chunks produces a different result? Or are you suggesting that, with the same chunking pattern, the result is still non-deterministic somehow? I could imagine the former kind of bug, but I'm not sure about the latter. If the former, I don't see follow how an attacker might control the division into records. It's easy in TLS 1.2, but we punted compression from 1.2, and in TLS 1.3, the handshake records are encrypted. Either way, I'm also not sure I've ever seen a TLS stack that processes messages chunk-by-chunk. Usually the message is reassembled from multiple records, if necessary, and then only processed when complete. I'm sure, in the vast space of implementations, such a stack exists, but it seems the same transcript consideration then applies without compression. Otherwise you'd need a correct streaming version of all TLS message parsing, ASN.1, and whatever else TLS calls into. Those are ad-hoc whereas decompression implementations are at least intended to stream correctly. (Then again, decompression is also a bit more complicated, probably.) Did I understand the issue correctly? On Thu, Mar 22, 2018 at 12:04 PM Subodh Iyengar <sub...@fb.com<mailto:sub...@fb.com>> wrote: 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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=yZJNzjyJxeApb_xGj4SpKqxVUsFz0DyksR6sTiyXlR4&s=sdRxUMYuldew6KHHPkg-b0LPwURwzvSq_9t95kFD2ss&e=>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
