- From: Benjamin Kaduk <kaduk@mit.edu>
- Date: Thu, 6 Jan 2022 14:29:09 -0800
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Éric Vyncke <evyncke@cisco.com>, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-http2bis@ietf.org, The IESG <iesg@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jan 06, 2022 at 02:17:26PM +0000, Cory Benfield wrote: > On Wed, 5 Jan 2022 at 12:10, Éric Vyncke via Datatracker > <noreply@ietf.org> wrote: > > -- Section 6.1 -- > > The SEC AD will obviously have the final word on this but wouldn't random > > padding be more secure (at the expense of later compression of course) ? > > I'm not really qualified to draw a conclusion here, but my layperson > view is that padding is only useful within an encrypted tunnel > provided by TLS, so the specifics of what the padding bytes _are_ > should not matter: the TLS stream cipher should make their specific > byte value entirely unobservable. And it's way cheaper to assemble > zero bytes than it is to assemble random ones. You can also verify > that padding has been done correctly if you use zero bytes (though > probably you shouldn't, lest you anger Daniel Bleichenbacher). Since a SEC AD was summoned, I'll confirm that this reasoning is basically sound. Using random rather than constant padding would interact differently with compression techniques, but we already warn against compression and for good reason, so the distinction is mostly irrelevant. -Ben
Received on Thursday, 6 January 2022 22:29:40 UTC