I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just one more conditional to save a few bytes (you need padding to exist anyway), and if you're doing 0-RTT, you're about to send a lot more bytes anyway.
-Ekr On Sun, Oct 30, 2016 at 12:52 PM, David Benjamin <david...@chromium.org> wrote: > Sounds reasonable. > > One concern is the F5 bug's failure mode was a timeout rather than an > error, so, if you take away padding, the allowance in C.3 will not save > heterogenous deployments where some servers do 1.3 and some are old F5 > servers. But given we're talking about a straight-up server bug now, it > seems reasonable for a client to say, okay, I will try to account for > heterogenous 1.2 and 1.3 deployments because that's kinda operationally > tricky, but if you've got that F5 bug, please fix it already. > > David > > > On Sun, Oct 30, 2016 at 6:03 AM Martin Thomson <martin.thom...@gmail.com> > wrote: > > (Trivial optimization warning) > > Just perusing my draft and noticed that NSS pads a 0-RTT handshake, > which is not that surprising given that it's fairly beefy (it will get > even larger in -18). Since a 0-RTT handshake will break servers that > don't at least superficially understand TLS 1.3, maybe we could avoid > pading in this case. Is there any reason we shouldn't include that > advice in the draft? > > _______________________________________________ > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
