On 02 Dec 2015, at 06:02, Martin Thomson <martin.thom...@gmail.com> wrote: > On 1 December 2015 at 08:22, Bryan A Ford <brynosau...@gmail.com> wrote: >> The 2-byte length field in each record's header no longer indicates >> the length of the *current* record but instead indicates the length of >> the *next* record. > > Ensuring that you know the length of the *next* record is difficult > and could dramatically degrade latency, or adding extra bogus padding > or extra bogus records. For instance, I can always send in bursts of > two packets, a one octet packet that promises the remainder of the > burst and one that promises a single octet packet. At that point, I > get to do what I've always done and you have gained little other than > an increase in packet size of around 19 octets (best case).
That type of inefficiency is extremely easy to avoid; please read the rest of my proposal where I discussed exactly that at length. Yes, a particularly stupid implementation could send everything in bursts of two packets, but it’s ridiculously easy for a slightly smarter implementation to avoid doing that. And what you’ve gained is complete encryption and integrity-checking of the whole TLS record before any part is interpreted, which seems like a nontrivial security improvement. B
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
