Thanks. What sort of errors are we trying to avoid by making sure implementations have to check for zeroed padding? Are we really worried some sloppy implementation is going to leave it uninitialized in a memory-unsafe language and just encrypt an arbitrary block of memory? This was mentioned at some point, and sounds really stupid, but planning for the stupid is probably a good idea.
Dave On Tuesday, September 22, 2015 09:18:53 pm Eric Rescorla wrote: > "Versions of TLS prior to 1.3 had limited support for padding. This padding > scheme was selected because it allows padding of any encrypted TLS record > by an arbitrary size (from zero up to TLS record size limits) without > introducing new content types. The design also enforces all-zero padding > octets, which allows for quick detection of padding errors. > " > > On Tue, Sep 22, 2015 at 4:45 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: > > > On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote: > > > I’ve gone ahead and posted the minutes/list of decisions to: > > > > > > > > https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3 > > > > That has this: > > > > > For padding, we reached a very rough consensus to start with the content > > type followed by all zeros (insert reasons why) over the explicit length > > option (insert reasons why). DKG to propose a PR that we'll then fight out > > on the list. See PR #253. > > > > The "reasons why" that were discussed were not inserted. ;) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
