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> 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 > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
