Hi Yoav, Thanks for the answers - much appreciated.
On 27/01/2018, 19:31, "Yoav Nir" <ynir.i...@gmail.com> wrote: > The length field is byte-aligned. So any implementation of a TLS > parser or TLS proxy will do one of two things: > > 1. Consider the MSB to be a must-be-zero bit and drop any length field > that has it set as faulty. > > 2. Ignore text about limits on length and assume the record is that > big. Depending on what field that is, this may cause a drop on some > other sanity check. > > As always there’s option #3 (crash), but the industry is getting > better at avoiding that. > > You seem to want the behaviour that the middlebox masks out the > must-be-zero bits and considers only the relevant length bits. I don’t > think that would pass code review at my former employer. What I was thinking was rather "once handshake is done and client has successfully passed the SNI checks, just blindly copy the byte stream across." I had this specific mental model (that of an HTTPS filter) in my head, which of course is just one of many. If the use case is "check for data exfiltration or covert channels", then the box is probably going to be a fully-fledged interception proxy. In that case the parser can't be sloppy, and the bit will not go through unnoticed (as you correctly note above). But - pardon a naive mind - these look like the kind of boxes that you can't just switch on and forget about. Instead, I'd imagine you need to keep their release cycle aligned with that of the endpoints, especially browsers, which tends to be pretty aggressive. (But yes, one thing is the vendor release cycle, and a completely different one is the network operator's upgrade schedule...) Since you are here, and you have amassed a considerable amount of wisdom in this space, I have a further question: Is, in your opinion, DTLS in a better spot than TLS WRT the use of that bit? Cheers and thanks again _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
