On Thu, Mar 22, 2018 at 04:58:57PM +0000, David Benjamin wrote: > 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.
As I read it, it was the latter: Nondeterministic result with the same chunking. > 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.) I think BearSSL processes messages chunk-by-chunk. I think it even can process individual X.509 certificates chunk-by-chunk. The reason why chunk-by-chunk processing is so rare is how difficult it is to program. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
