On Thu, Jun 16, 2016 at 12:13:28PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > > wasn't that rejected because it breaks boxes that do passive monitoring > > of connections? (and so expect TLS packets on specific ports, killing > > connection if they don't look like TLS packets) > > We're talking about the possibility of changing the TLS record framing > anyway, which would kill the simplest of those boxes. One theory is if > you're going to make such a break, you might as well pull the band aid > off in one fell swoop.
One scheme with minimum overhead (3 bytes + crypto tag + padding) to that doesn't do record hiding, is not compatible with multiple keys nor SRTP mux: - Bit 7 of first byte: 0 => normal TLS 1.0-style 5 byte header. 1 => 2 bytes, low 15 bits are length of encrypted record. And then do draft-13-style padding inside encrypted envelope. If one wants to do record hiding and MAC the headers, one would presumably want 64-bit tags due to space usage. Unfortunately, algebraic MACs tend to be rather weak at 64-bits (forgeries tend to give up lots of information about the key) and non-algebraic ones (based on hashes) tend to be a bit slow. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
