Should we support padding for Enveloped/Encrypted Messages

[jimsch]

padding of content is useful for dealing with traffic analysis attacks. This can be seen as becoming important as it is now part of the basic framework of TLS 1.3.

We currently do not have any facility to do a generic padding and it is not clear that we should provide one. The benefit is that it would allow for the ability to reduce the set of traffic analysis attacks. The down side is that we probably need to have some type of length field added to encrypted content for all messages. This means that we potentially have a single byte (or more depending on how it is done) to all messages increasing the length. It is also not clear yet how much the IoT world cares about doing the type of protection in the near term. (It is possible that in time they may start caring.)

One possible answer is to add the padding to the end of the current message ala the PKCS#7 padding. There would be N bytes appended to the end of the message, each containing the value of N. The default would be to append a single byte with the value of '1'.

The use of padding would be described as being application specific rather than being generic. However the single byte would always need to be paid even if there was not padding done.

[selfissued]

I agree that no change is needed to add this. Applications can always define their payloads in a way that includes padding, if appropriate.