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

From: "Jim Schaad" <[email-masked]>
Date: Sat, 6 Feb 2016 19:56:39 -0800

Before I close this issue, does anyone else want to weight in?

Jim

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, January 04, 2016 2:09 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ace] Should we support padding for Enveloped/Encrypted
> Messages
> 
> 
> 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:
> > 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
> >
> >
> > _______________________________________________
> > Ace mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ace
> >
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace