Subject: [Ace] Should we support padding for Enveloped/Encrypted Messages

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Jan 2016 13:28:34 -0800

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.  One possible simple analysis that can be performed against
sensors is looking for thresholds in reported values.  Just looking at the
message length, one can tell the difference between '9.0' and '10.0' unless
the first item is padded out to the same length.  For example using either
'09.0' or ' 9.0'.  

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.

At this time my inclination is to treat this as a problem that the
application should be solving and to simply address it as a security
consideration in the COSE message draft.

Any comments?  I would like to resolve this by the end of this week.

Jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Jan 2016 22:08:30 +0000

I would argue to try define a padding mechanism here.

As you note, it may be important later and there are some real
issues when dealing with constrained use-cases. In fact, in the
limit one might want to define a padding-only form for COSE to
handle the case where the existence of any traffic defeats any
confidentiality protection. (E.g. sensor that fires a packet
when temp==20C.) I know that that'd not often be useful but I
think there will be times when it will.

The argument that applications can best do this is not a bad one,
but can be countered. If a node has a common crypto library that
ensures that padding can be done consistently across multiple
applications, which could be harder if not defined at this layer.
(And even more likely, application developers don't care or don't
bother or don't know how to do this well.)

Cheers,
S.

PS: FWIW, I'd make the same argument for any protocol - I think
we need to define basic padding mechanisms whenever we can now
so that we or others can learn how to best use those later.

On 04/01/16 21:28, Jim Schaad wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>