On Sun, Oct 30, 2016 at 2:13 PM, Martin Thomson
wrote:
> On 31 October 2016 at 06:58, Eric Rescorla wrote:
> > 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
On 31 October 2016 at 06:58, Eric Rescorla wrote:
> 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.
0-RTT happens wh
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
wrote:
> Soun
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 no
(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
